Будет массив с числами, числа не по порядку, поэтому не диапазон, а список.
Числа - номера в названиях интерфейсов.
Трафик на интерфейсы балансируется через Per Connection Classifier.
Если какой-то из интерфейсов падает, в PCC нужно менять метку, чтоб трафик пошел через другой рандомный интерфейс.
Далее пралнируется еще написать проверку на то, доступен ли тот интерфейс, куда будет перенаправляться трафик с упавшего, но это потом...
На мой взгляд тут закралась ошибка в проектировании. Какой смысл колхозить скрипты чтобы переписывать метки, когда эти метки ссылаются на маршруты, которые падают при падении интерфейса. Если интерфейс по факту не падает, а падает лишь транзит трафика, то есть смысл настроить рекурсивные маршруты, чтобы эти маршруты валились тогда, когда транзит трафика через интерфейс становится невозможным по какой-либо причине. И вся эта схема будет работать в полностью автономном режиме без какого-либо скриптования. Хотя если у провайдера будут меняться настройки, прилетающие по dhcp, то скриптануть немного все-же придется. На этапе получения настроек будет необходимо менять/добавлять/удалять gateway в маршруте с меткой.