Burkhard Linke writes: > I'm curious.....what is the advantage of OSPF in your setup over > e.g. LACP bonding both links? Good question! Some people (including myself) are uncomfortable with LACP (in particular "MLAG", i.e. port aggregation across multiple chassis), and with fancy L2 setups in general. Concrete issues include * worries about compatiblity between different MLAG implementations, which tend to vary subtly between vendors * worries about general reliability of L2 in complex topologies with lots of potential loops - as soon as spanning tree makes ONE brief mistake you can end up with broadcast storms and subsequent meltdowns * requirement to have direct inter-switch links between switches that share a VLAN with LACP; this runs counter to the fashionable "Clos" (aka fat-tree aka leaf/spine) topology. (Also you are talking about "both links"... I don't know about LACP, but with OSPF it's trivial to use arbitrary numbers of uplinks - e.g. 3 - to arbitrary routers/switches; you can also move servers around freely between "leaf" switches.) With modern L3 routing protocol implementations, you can use simple and generic configurations using "unnumbered" routing adjacency definitions. OSPF has had this for a long time, and modern BGP implementations (e.g. FRR) also do. This neutralizes one of the most important advantages of L2 networks, namely easy configuration. Routing protocols such as OSPF, IS-IS, or BGP-4 have proven their robustness in dynamic and wild environments, e.g. the Internet. IP forwarding also has the wonderful "TTL" mechanism, which makes the occasional routing loop much less disastrous. By the way, a thoroughly "unnumbered" routing configuration can alleviate the original poster's problem, because it lets you use a single IP address (or a single IPv4 + a single IPv6 address...) across all interfaces. We use this in our setup, previously with OSPF(v2+v3), now using BGP-4, between hosts running Ubuntu+FRR and switches running Cumulus Linux (also with FRR) following Cumulus Networks's "routing to the host" model. -- Simon. _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |