[c-nsp] 3750 switch stack

[Gyebnár Krisztián]

thx Robert,

Yes, earlier we did this:

Switch#  Role      Mac Address     Priority     State
--------------------------------------------------------
*1       Master    0011.218c.f180     15        Ready
 2       Slave     0012.0118.ba80     14        Ready
 3       Slave     0012.0118.5b80     13        Ready
 4       Slave     0012.0108.3300     12        Ready
 5       Slave     0012.0118.1d80     11        Ready
 6       Slave     0012.010a.8300     10        Ready

if i reload the Master: no problem the switch 2 become the master(priority 
14)

and if the switch 1 (the old master with priority 15) come up again he 
trigger all others in the stack to reload and do stack master election;

the problem is the "reload",  because this mean 2 minute outage in the 
entire switch network and in the service (240 Fastethernet port down)

Krisztián



----- Original Message ----- 
From: "Robert Hayden" <rhayden at doit.wisc.edu>
To: "Gyebnár Krisztián" <gyebi at freemail.hu>
Cc: <cisco-nsp at puck.nether.net>
Sent: Tuesday, April 12, 2005 6:04 PM
Subject: Re: [c-nsp] 3750 switch stack


> Make sure you set the switch priority when you configure up the stack.
>
> We set up as follows:
>
> Slot 1:  Priority 15
> Slot 2:  Priority 14
> Slot 3:  Priority 13
> ... etc
>
>
> That way your stack will always come up in the order that you want.  If 
> slot 1 dies, slot 2 takes over as master.  Adding a new switch will fill 
> in the slot void with a priority of 1, you then reprioritize it back to 15 
> to make it the master again.
>
> Note that when you reboot a stack, it will ALWAYS do a master election 
> while all the switches talk to each other to see who has the highest 
> priority, or if they are all the same, fall back to other election rules.
>
>  - Robert
>
> Gyebnár Krisztián wrote:
>> Hi,
>>
>> We have new 3750 switch stack (1 3750-16 and 5 3750-48); These switches 
>> connected together into a big switch stack also 3750-16 is the stack 
>> master; So, we test the stack with interrupt the stack members 
>> randomly(pull down the stackwise cable or power down/up the members:-), 
>> the results is very good:
>> if the switch has live connection to the stack master the forwarding 
>> capability is perfect.
>>
>> If we fully pull down/reload the stack master, the remaining stack 
>> members elect a new stack master without any problem (forwarding 
>> interrupt).
>>
>> BUT:
>>
>> At the time, when the old stack master pull/power up again the all of 
>> stack members says: new stack master found and reboot for stack master 
>> election...
>>
>> ??? WHAT ???
>>
>> and so all stack member (if i remember correctly: include the stack 
>> master ) do reload.
>>
>> After this(2 min outage) i have fully functional stack again, but this 
>> way to elect new (the previuos old) stack master with reload the entire 
>> stack is (hmmm) very interesting.
>>
>> Have anybody experience with this switch family (or stacking in live 
>> environment) ?
>>
>> THX
>>
>> Krisztián
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>