Migrating N series switches to stack config

1. I suggest following this KB article when creating the stack: https://dell.to/2NlqPvw
- backup switch config
- update switches
- configure ports for stacking
- shutdown switches
- cable switches
- power on stack master
- power on stack backup

2. Correct, once the switches are stacked, they will behave as one logical unit.

3. You will not be able to SSH/Telnet directly to the member switches. The entire stack is managed as one unit, through the master switch. You can make a serial connection to the member switches, but you will not be able to do much.

4. If a device only has a connection to one switch in the stack, and that switch goes down, then the device no longer has a connection to a stack. A common task with stacked switches, is to provide link redundancy through the use of link aggregation. https://dell.to/2Gz3JQ9

Hope this helps

Hello Daniel,

thanks for your fruitful answer.

The KB article on setup is exactly the one I had previously read, but, as you can see, it does not answer all my questions, to which satisfaction you have provided me interesting input.

As I got it, there is no particular order of the tengigabit ports for the cables, provided the resulting topology is a ring. Right?

Also, if I have correctly understood, the N1548 will become a mere extension of the N1524 and, therefore, will sport no IP or whatsoever.

What I haven't understood is what happens to the slave switch, should the master one die. You wrote that it detaches from the stack, which is obvious. There are still unsatisfied questions:

1. Does this imply that it will have a wiped away config? Or will it still have some?

2. Will it then have an IP? Or just serial console access? Or neither? If neither, will it need to be reset?

Btw, LAG would be a fine and elegant idea, the problem is that the uplink device is a Peplink 30 load balancer, and this model does not support LAG on LAN ports.

3. is there a way, apart from LAG, to map a port on slave switch just like an existing one on the master one which activates just in case of death of master switch, as a fallback? In that case bringing connectivity back would be as easy as moving one cable e.g. from port 1/0/1 to port 2/0/1.

Thanks!

Pasha

That is correct, connect the interfaces in a ring, it does not matter if they are crossed or not. The additional stack members will not have any additional configurations, including IP addresses.

The master switch will house the configuration and the backup switch will keep a synced copy of the configuration. If the master switch goes down, the backup unit will take over as the new master, using the synced configuration file it has. When the backup unit becomes the master unit, it will then be accessible just like the previous master unit.

 I think probably the best approach, would be to enable spanning tree on the Peplink 30, and let spanning tree place one of the interfaces into a discarding state. Having it configured this way, would allow one interface to be forwarding while the second interface is discarding. If the forwarding interface goes down, then the switch would see that there is no longer a loop and would place the discarding interface into a forwarding state.

Thank you for your interesting answer!

Actually I have zero experience with STP, so my question is: should it be supported even on the Peplink or does it suffice to have it on the switches? This, because, of course, the peplink doesn't support it too.

In case the two switches would suffice, how would you configure the two ports on them?

Thanks

Pasha

The user guide indicates that spanning tree is supported.

Page 95: https://bit.ly/2LUBxsU

Spanning tree needs to be supported by both devices for it to be operational. Without the use of link aggregation or spanning tree, you might be able to configure each interface on the peplink with different IP addresses and then configure two static routes on the switch. Give one route a lower priority so that it is preferred over the other. You would need to do some testing to confirm if this kind of setup works.

Page 1494: https://dell.to/2OjHQI4

Thanks,

I had already went though that man page, and not only the STP is only within a VPN WAN only scope, but, in any case, available only on higher models and not on Peplink 30.

But I think you gave me the right clue about ip policy route-map, looks like we're on the right path to make things work! Now, the vlan that talks with uplink is vlan 255 over a single port on N1524. When the N1548 will be stacked, besides allocating another port to vlan 255 on it, should I set the "ip policy route-map" over just the vlan or specifying ports or what?

Could you make a syntax example for this situation? Say ports are current 1/0/1 and future 2/0/1.

Thank you very much :)

Pasha

I was referring to static route entries.

# ip route 0.0.0.0 0.0.0.0 {ip address of peplink interface 1} 5

# ip route 0.0.0.0 0.0.0.0 {ip address of peplink interface 2}10

The route map is used when configuring policy based routing. There may be a way of using policy based routing, but I'm not certain what that config would look like.

Thank you, I will use this approach.

Have a nice day!