I need to implement a active/backup szenario over 4 interfaces, which need to be activated in a specific order. So let us assume vlan10 will be the default connection. vlan11 will be the next interface to become active if available, followed by the interfaces vlan210 and vlan211.
Can this be achieved by using a bonding interface with 4 slaves?
If not, what would be the best way of implementing this scenario? Only one active connection is needed.
Re: Bonding with four slave interfaces and specific requirements for activation order
Bonding doesn't allow to use only one of four links at a time with priority.
As you've mentioned VLANs, I assume you don't need L2 transparency on the redundant connection?
Connecting two L2 segments using various VLANs is quite an unusual approach and has some caveats, but on the other hand, a careful misuse of RSTP might fulfil what you actually need.
One of more conventional methods,
So specify your requirements for failure detection speed and L2/L3 transparency.
As you've mentioned VLANs, I assume you don't need L2 transparency on the redundant connection?
Connecting two L2 segments using various VLANs is quite an unusual approach and has some caveats, but on the other hand, a careful misuse of RSTP might fulfil what you actually need.
One of more conventional methods,
- routes with different distance values,
- dynamic routing protocol like OSPF,
- scriptless redundancy based on recursive next-hop search,
- scripted redundancy
So specify your requirements for failure detection speed and L2/L3 transparency.
Re: Bonding with four slave interfaces and specific requirements for activation order
Thx for answering. Well, I try to explain my setup: two redundant gateway router serve two redundant lan router; they are physically connected by a single switch and traffic is forced through a single transparent proxy. If the switch fails traffic should flow through direct connection; if the proxy fails traffic should flow though a bypass connection between gw and lan router; if both fail direct connection bypassing the proxy should be used.
It is a small business setup, so failover speed is secondary and if I get it right L2 transparency is not needed. Recommended setups 1) and 2) had been in place, scripting is not preferred but what is 3) recursive next hop search?
vlan's are used cause physical connections carry both bypass connection and connection via transparent proxy.
It is a small business setup, so failover speed is secondary and if I get it right L2 transparency is not needed. Recommended setups 1) and 2) had been in place, scripting is not preferred but what is 3) recursive next hop search?
vlan's are used cause physical connections carry both bypass connection and connection via transparent proxy.
Re: Bonding with four slave interfaces and specific requirements for activation order
Scriptless redundancy based on recursive next-hop search uses check-gateway=ping to monitor immortal addresses somewhere behind the uplink, so if L1/L2 on the uplink is fine but the path to the monitored IP address is broken somewhere further, the uplink is detected to be unusable. The coarse description is - instead of setting a default route (0.0.0.0/0) directly via an uplink's gateway, you set a specific /32 route to the monitored address (e.g., 8.8.8.8) via that gateway; the route to 0.0.0.0/0 has the monitored address as a gateway. So if 8.8.8.8 is pingable, the route to 0.0.0.0/0 via 8.8.8.8 is active; when the path to 8.8.8.8 via that uplink is broken for any reason, the default route via 8.8.8.8 becomes inactive within 10 seconds (check-gateway=ping uses a 10s interval which cannot be changed).
So you need a monitored address (or better two if you suspect the single one not to be immortal enough) per uplink which in your case of four uplinks may be a bit of a problem, but you need no scripting for the failover, as the embedded mechanisms take care of it.
The gateways MUST be plain IP addresses for this to work (no interface names, no ip.add.re.ss%interface-name constructs are accepted). And the scope and target-scope parameters of some of the recursive routes need to be adjusted to make it all work. The details are e.g. in this nice article.
So you need a monitored address (or better two if you suspect the single one not to be immortal enough) per uplink which in your case of four uplinks may be a bit of a problem, but you need no scripting for the failover, as the embedded mechanisms take care of it.
The gateways MUST be plain IP addresses for this to work (no interface names, no ip.add.re.ss%interface-name constructs are accepted). And the scope and target-scope parameters of some of the recursive routes need to be adjusted to make it all work. The details are e.g. in this nice article.
Re: Bonding with four slave interfaces and specific requirements for activation order
Thx for your explanation.
To cut it short I need to use routing technologies rather than bonding. Gonna work it out...
To cut it short I need to use routing technologies rather than bonding. Gonna work it out...
Re: Bonding with four slave interfaces and specific requirements for activation order
That was the message of the very first sentence in my first reaction 
As there is a switch in the scenario, the "creative misuse" of RSTP is also out of question, so yes, you're limited to routing techniques.
As there is a switch in the scenario, the "creative misuse" of RSTP is also out of question, so yes, you're limited to routing techniques.