[j-nsp] MX Virtual Chassis?
Saku Ytti
saku at ytti.fi
Thu Jan 10 13:13:10 EST 2013
On (2013-01-10 12:41 -0500), Darius Jahandarie wrote:
> With multi-chassis technology you can gain something which was not
> possible without it, namely the ability to protect against total
> hardware failure of your direct uplink switch/router by using an
> MC-LAG to your server.
If your server is linux, you can run 'bonding' to two different switches
and you can use ARP liveliness detection to figure out when to switch to
another port.
Also emerging quite common pattern is to scale servers horizontally, where
single server is not crucial to produce service. Then liveliness of service
be advertised by BGP (e.g. exabgp).
But granted, when you have proprietary service or server, which is SPOF in
itself where you cannot influence of it's configured at all you may be out
of options and may need to do something desperate.
Personally if I find myself in such situation I'd accept that MTBF is going
to be bad, and I'd opt to make MTTR small. So cold box sitting in another
infra which I can remotely kick up, if the primary fails.
I don't think, that even in such situation, multichassis will improve MTBF.
--
++ytti
More information about the juniper-nsp
mailing list