Here is a sample of what I've been thinking about as a cluster (as in
multiple boxes in one file) network configuration file. Its no where
near done, I know it needs a little more work on the configuration of
bridges among other types of interfaces, and the scripts to use it
haven't been written yet but it should give any one intrested a good
idea of where I'm thinking of going with it. also I forgot to mention
I was thinking of also adding some optional basic configurations for
quagga to add OSPF and BGP support, and eventually user definable
hooks to execute scripts before and after key actions.

<?xml version="1.0" encoding="UTF-8"?>
<XML>
    <CLUSTER>
        <NODE>
            <!-- UUID number retrived via `dmidecode -s system-uuid` -->
            <UUID>32393735-3733-5355-4531-30374E36445A</UUID>
            <NAME>firewall01.example.net</NAME>
            <ADDRESS>
                <IP>192.168.1.2/24</IP>
                <!-- VLAN may be ignored for bridges -->
                <VLAN>1300</VLAN>
                <BRIDGED>
                    <NAME>br0</NAME>
                </BRIDGED>
                <!-- This Interface tag is ignored if the adress is
assigned to a bridge -->
                <INTERFACE>bond0</INTERFACE>
                <ROUTE>
                    <TARGET>10.150.99.0/24</TARGET>
                <GATEWAY>192.168.1.8</GATEWAY>
                </ROUTE>
                <ROUTE>
                    <!--  the priority sequience of the route -->
                    <PRIORITY>5</PRIORITY>
                    <TARGET>default</TARGET>
                    <!-- optional name of a routing table for rule
based routing -->
                    <TABLE>loadbalanced</TABLE>

                    <!-- weighted load balancing of routes betwean two
gateways -->
                    <!-- If you are using nexhop the gateway must be
in the NEXTHOP tag -->

                    <NEXTHOP>
                        <GATEWAY>192.168.1.5</GATEWAY>
                        <!-- Bandwidth based load balancing weight -->
                        <WEIGHT>1</WEIGHT>
                    </NEXTHOP>
                    <NEXTHOP>
                        <GATEWAY>192.168.1.6</GATEWAY>
                        <WEIGHT>5</WEIGHT>
                    </NEXTHOP>
                </ROUTE>
            </ADDRESS>
            <ADDRESS>
                <IP>192.168.2.2/24</IP>
                <VLAN>1301</VLAN>
                <BRIDGED>
                    <NAME>br1</NAME>
                </BRIDGED>
            </ADDRESS>
            <!-- More than one bridge interface can be defined -->
            <BRIDGE>
                <ENABLED>TRUE</ENABLED>
                <NAME>br0</NAME>
                <TRANSPARENT>FALSE</TRANSPARENT>
                <SPANINGTREE>
                    <ENABLED>FALSE</ENABLED>
                </SPANINGTREE>
            </BRIDGE>
            <BRIDGE>
                <ENABLED>TRUE</ENABLED>
                    <NAME>br1</NAME>
                    <!-- In transparent mode the physical interfaces
are set to promiscuous mode and the ip addresses if any are assigned
to the bridge -->
                    <!-- In non tranparent mode the ip addresses are
assigned to the interfaces with a /32 mask and the routes are applied
to the bridge -->
                    <!-- Additionally in non transparent mode a static
neighbor maping to the broadcast address to mac address
ff:ff:ff:ff:ff:ff will be added to the bridge-->
                    <TRANSPARENT>FALSE</TRANSPARENT>
                    <!-- yes we can do this spanning tree is possible
on Linux if you use a bridge device but sorry no RSTP -->
                    <SPANINGTREE>
                        <ENABLED>TRUE</ENABLED>
                        <PRIORITY>1</PRIORITY>
                        <FORWARDDELAY>0</FORWARDDELAY>
                        <HELLOTIME>1</HELLOTIME>
                        <MAXAGE>2</MAXAGE>
                        <!-- Spanning tree based dynamic routing -->
                        <PORT>
                            <NAME>bond0</NAME>
                            <VLAN>1301</VLAN>
                            <!-- see
http://en.wikipedia.org/wiki/Spanning_Tree_Protocol#Data_rate_and_STP_path_cost
-->
                            <COST>4</COST>
                            <PRIORITY>1</PRIORITY>
                        </PORT>
                    </SPANINGTREE>
            </BRIDGE>
            <NEIGHBOR>
                <IPADDRESS>192.168.1.5</IPADDRESS>
                <DEVICE>br0</DEVICE>
                <LINKADDRESS>a1:2d:3a:f0:1f:9c</LINKADDRESS>
                <STATE>permanent</STATE>
            </NEIGHBOR>
            <INTERFACE>
                <!-- The name doesnt have to match the physical device
or type of device you can actually name it whatever you want -->
                <NAME>bond0</NAME>
                <DEVICE>eth0</DEVICE>
                <DEVICE>eth1</DEVICE>
                <BONDING>
                    <ENABLED>TRUE</ENABLED>
                    <MODE>1</MODE>
                    <OPTIONS></OPTIONS>
                    <NAME>bond0</NAME>
                </BONDING>
            </INTERFACE>
            <!-- used for policy based routing -->
            <ROUTINGTABLE>
                <!-- the name of the routing table -->
                <NAME>loadbalanced</NAME>
                <!-- For use with iptables mark option for rule based
routing -->
                <MARK>100</MARK>
            </ROUTINGTABLE>
        </NODE>
        <NODE>
            <!-- UUID number retrived via `dmidecode -s system-uuid` -->
            <UUID>5FEAA22F-7674-2539-9D99-3A7158BCC973</UUID>
            <NAME>firewall02.example.net</NAME>
            <BRIDGE>
                <ENABLED>TRUE</ENABLED>
                <NAME>br1</NAME>
                <!-- in transparent mode the physical interfaces are
set to promiscuous mode and the ip addresses if any are assigned to
the bridge -->
                <!-- in non tranparent mode the ip addresses are
assigned to the interfaces with a /32 mask and the routes are applied
to the bridge -->
                <TRANSPARENT>FALSE</TRANSPARENT>
                <!-- yes we can do this spanning tree is possible on
Linux if you use a bridge device but sorry no RSTP -->
                <SPANINGTREE>
                    <ENABLED>TRUE</ENABLED>
                    <PRIORITY>1</PRIORITY>
                    <FORWARDDELAY>0</FORWARDDELAY>
                    <HELLOTIME>1</HELLOTIME>
                    <MAXAGE>2</MAXAGE>
                    <!-- Spanning tree based dynamic routing -->
                    <PORT>
                        <NAME>bond0</NAME>
                        <VLAN>1301</VLAN>
                        <!-- see
http://en.wikipedia.org/wiki/Spanning_Tree_Protocol#Data_rate_and_STP_path_cost
-->
                        <COST>4</COST>
                        <!-- Each spanning tree port must have a
unique priority number -->
                        <PRIORITY>2</PRIORITY>
                    </PORT>
                </SPANINGTREE>
            </BRIDGE>
            <INTERFACE>
                <!-- The name doesnt have to match the physical device
or type of device you can actually name it whatever you want -->
                <NAME>bond0</NAME>
                <DEVICE>eth0</DEVICE>
                <DEVICE>eth1</DEVICE>
                <BONDING>
                    <ENABLED>TRUE</ENABLED>
                    <MODE>1</MODE>
                    <OPTIONS></OPTIONS>
                    <NAME>bond0</NAME>
                </BONDING>
            </INTERFACE>
            <!-- used for policy based routing -->
            <ROUTINGTABLE>
                <!-- the name of the routing table -->
                <NAME>loadbalanced</NAME>
                <!-- For use with iptables mark option for rule based
routing -->
                <MARK>100</MARK>
            </ROUTINGTABLE>
        </NODE>
    </CLUSTER>
</XML>



On Sun, Aug 18, 2013 at 1:53 PM, Paul Robert Marino <[log in to unmask]> wrote:
> I totally disagree I love NM on my laptop but its a pox upon my servers. It
> causes far more problems for servers than it fixes.
> For one thing if I have a process bound to an IP and NM stops that interface
> due to a transient issue with the network such as a switch rebooting or some
> one accidentally unplugging the wrong cable in the patch panel for a split
> second. The problem is it brings the interfaces down when link is lost.
> However the file handle for the network socket stays in a "DELETED" state
> until the the service is restarted or the service detects an issue with the
> socket because the programmer was better than average and though about the
> scenario. Now the link comes back but the socket is still broken because it
> still points to the deleted file handle for the old link so it spears
> although my service is working but in reality it can't hear new connections
> coming in. By the way this scenario doesn't apply to things bound to the
> default 0.0.0.0.
>
> Also the fact that I saw it decide on its own to bridge several interfaces
> together last week on a CentOS 6.4 box because a consultant made a mistake I
> just don't trust it.
>
>  In fact I've been thinking I just may scrap it all the redhat network tools
> and write a ground up replacement for the firewall tools I'm writing right
> now (yes the will be released under the GPL when they are ready).
> I'm thinking thinking I'll do something similar to what I did with Fedora 4
> back in the day when I worked for a network secuity appliance company with
> an XML based config for the network interfaces. But I think I can get away
> with a simple set if small scripts that mostly just do XSLT transforms to
> create the appropriate commands for iproute2 this would mean that adding or
> modifying features would simply be a matter of updating a DTD or schema and
> the XSLT file. Also I'm thinking of possibly integrating iptables and ipset
> into it as well. Since I already have successfully compiled and tested ipset
> on RHEL 6.x and already have the tools and sysV init scripts written for
> them based on a slightly modified (I added to it but didn't change any thing
> already in it) version of the XML dumped by the ipset command.
>
>
>
>
>
> -- Sent from my HP Pre3
>
> ________________________________
> On Aug 18, 2013 12:42, Tom H <[log in to unmask]> wrote:
>
> On Mon, Aug 12, 2013 at 10:24 AM, Paul Robert Marino
> <[log in to unmask]> wrote:
>> On Wed, Jul 31, 2013 at 10:21 PM, zxq9 <[log in to unmask]> wrote:
>>> On 07/31/2013 11:57 PM, Tom H wrote:
>>>> On Tue, Jul 30, 2013 at 5:12 PM, zxq9<[log in to unmask]> wrote:
>>>>> On 07/30/2013 10:26 PM, Tom H wrote:
>>>>
>>>> I was only commenting on the more complex and unreadable spec files.
>>>> Otherwise I'm happy about systemd and journald. In short, the kernel
>>>> has evolved, the applications have evolved, why not the init system?
>>>
>>> Its not that the init system can't do with some modernization, its that
>>> the
>>> new system has a severe case of featuritis that is spawning little eddies
>>> of
>>> nonlocalized complexity all over the place. Modernizing a system and
>>> tossing
>>> everything that's come before in the interest of a deliberately
>>> incompatible
>>> rewrite are different things. Remember HAL?
>>
>> well thats mostly due to the fact that its new and far more complex.
>> there was a mad rush for every one to rewrite there statup scripts and
>> quite a few of them weren't done very well and others weren't fully
>> thought out.
>>
>> what I find worse is they did a ground up rewrite and didn't touch the
>> network configuration portion wasn't rewritten.
>>
>> The network scripts are limited and problematic if you want to do any
>> thing advanced. for example its a long story why but on one device a
>> bridge I have to add a static arp entry. iproute2 has been able to do
>> this for as long as i can remember but there was no clean way to get
>> it to work was to hack the network scripts in order to add the
>> functionality.
>>
>> Really the scripts network scripts need to have hooks added so user
>> defined scripts can be called at various points of the startup and
>> shutdown of an interface. but more than that they mostly date back to
>> the 2.0 Kernel and Linux's Network capabilities have change
>> significantly since then but for the most part these scripts keep
>> people stuck in the 90's.
>
> (Couldn't you top-post like everyone else?)
>
> There's been more than one hint on fedora-devel that the reason that
> the "/etc/sysconfig/network-scripts/<scripts>" haven't been adapted to
> systemd is that no one wants to do the (large amount of) work that
> would be required when the eventual goal is to default to NM and only
> use NM; and that that goal's ever closer. (As a Fedora user, I
> sometimes wish that TUV weren't so involved with GNOME and NM and that
> netctl were packaged for Fedora - and in the future for EL-7 - because
> it's integrated into systemd; but NM's slowly getting there for
> servers.)
>
> EL-6.4's network scripts mostly use iproute (although I don't think
> that you can use "PREFIX=24" instead of "NETMASK=255.255.255.0" as you
> can on Fedora).
>
> The following command returns nothing on F-19, but on EL-6.4:
>
> [root@sci6:/etc/sysconfig/network-scripts]# grep ifconfig *
> ifup-ippp: /usr/bin/logger -p daemon.info -t ifup-ippp "ifconfig
> $DEVICE $IPADDR pointopoint $GATEWAY $netmask up"
> ifup-ippp: ifconfig $DEVICE $IPADDR pointopoint $GATEWAY $netmask
> up >/dev/null 2>&1
> ifup-isdn: /usr/bin/logger -p daemon.info -t ifup-ippp "ifconfig
> $DEVICE $IPADDR pointopoint $GATEWAY $netmask up"
> ifup-isdn: ifconfig $DEVICE $IPADDR pointopoint $GATEWAY $netmask
> up >/dev/null 2>&1
> ifup-plip:ifconfig ${DEVICE} ${IPADDR} pointopoint ${REMIP}
> ifup-plusb: ifconfig ${DEVICE} ${IPADDR} pointopoint ${REMIP}
> netmask ${NETMASK}
> ifup-plusb: ifconfig ${DEVICE} ${IPADDR} pointopoint ${REMIP}
> netmask ${NETMASK}
> [root@sci6:/etc/sysconfig/network-scripts]#