Отказоустойчивый узел передачи данных

    Каждый оператор ШПД думает о том, как выпускать пользователей в сеть интернет и грамотно ограничивать скорость работы в сети по имеющимся тарифным планам и иметь резерв на случай отказа оборудования или работ связанных с отключением оборудования. Попытаюсь рассказать и показать на примере то, как это реализовано у нас (к нам подключены более 3х тысяч пользователей и описанный мною вариант работает очень даже неплохо)


    Для начала нам дано:
    1) 1U rack mount сервер (Intel Xeon E5335, 1GB Ram, двухпортовый NIC Intel PRO/1000 EB), у нас таких используется два. Для чего – расскажу в тексте статьи
    2) Пограничный маршрутизатор (в моем случае Juniper j4350, 2 штуки)
    3) L3 коммутатор поддерживающий протокол BGP или OSPF
    4) А также задачу: A) Имея все это хозяйство выпустить пользователей в Интернет.
    Б) сделать резерв, который в случае аварии будет задействован
    автоматически и без нашего участия

    Пограничный маршрутизатор (рекомендации)

    Начнем с с настройки пограничного маршрутизатора.
    Он может быть любой, хоть PC под FreeBSD/Linux со всем известным пакетом Quagga, а может быть оборудованием производителей Cisco или Juniper. Как настроить пограничный маршрутизатор на PC c пакетом quagga или cisco очень много статей в интернете и много подробной документации (да, конфиг кваги идентичен конфигу cisco). По джуниперу тоже есть информация, не так много, но есть. Да и тема статьи не про настройку пограничного маршрутизатора и протокола BGP на нем, а немного про другое.

    В моем случае в качестве пограничных маршрутизаторов используются два Juniper j4350, железка не очень мощная, но под текущие задачи и бюджет подходит как раз.
    Каждый из этих маршрутизаторов установлен на своем узле (узлы в разных местах) и к каждому из них подключен свой аплинк. Со стороны аплинков по bgp протоколу мы принимаем full-view и анонсируем им свои сети. А на шейперы мы отдаем по внутреннему bgp, в специально отведенном для этого vlan-e только маршрут по умолчанию (default route)
    Для джунипера это строчки в конфиге:
    Вprotocols bgp
    neighbor 195.xxx.xxx.226 { export [ default-originate reject ];

    В policy options
    policy-statement default-originate {
    from {
    route-filter 0.0.0.0/0 exact;
    }
    then accept;
    }, это чтобы отдать только маршрут по умолчанию
    policy-statement reject {
    then reject;
    } , а это чтобы отбросить все остальные маршруты.


    Пограничные маршрутизаторы настроили, каждый принимает full-view от аплинков и отдает наши сети. Теперь настраиваем vlan для внутреннего bgp, внутри него подымаем связь по протоколу bgp между пограничными маршрутизаторами для обмена маршрутами между ними. Выделяем IP адреса будущим шейперами, но желательно не один, а несколько, для пула внешних IP адресов используемых для NAT. В моем случае по 4-ре адреса на каждый шейпер, но вы можете больше или меньше. В зависимости от размера сети и количества абонентов.

    Настройка сервера для шейпирования и NAT на FreeBSD

    Достаем сервер из коробки, и начинаем устанавливать на него FreeBSD, лучше последней стабильной версии. Устанавливать FreeBSD желательно в самой минимальной комплектации, не забыв отметить порты и дерево исходных кодов ядра (после настройки можно удалить)

    После того как поставили FreeBSD, начинаем настраивать на ней сеть. В /etc/resolv.conf задаем адреса dns серверов и прописываем маршрут по умолчанию и IP адреса в файл /etc/rc.conf (не смотря на наличие bgp маршрут по умолчанию лишним никогда не будет, на случай проблем с квагой которую мы будем ставить далее)
    ------/etc/rc.conf----
    defaultrouter="195.xxx.xxx.225" #маршрут по умолчанию
    gateway_enable="YES" #включаем режим пересылке пакетов между интерфейсами
    hostname="gw2.xxx.ru" #задаем имя маршрутизатора
    # em0 – внешний интерфейс в влане c внутренним bgp
    ifconfig_em0="up"
    ifconfig_em0="inet 195.xxx.xx.231 netmask 255.255.255.240" #освновной IP адрес
    ifconfig_em0_alias0="inet 195.xxx.xxx.232 netmask 255.255.255.255" #дополнительные IP.
    ifconfig_em0_alias1="inet 195.xxx.xxx.233 netmask 255.255.255.255" #алиасы
    ifconfig_em0_alias2="inet 195.xxx.xxx.234 netmask 255.255.255.255"
    #em1 – внутренняя сеть, в моем случае это vlan между шейперами и l3 коммутаторами
    ifconfig_em1="up"
    ifconfig_em1="inet 195.xxx.xxx.193 netmask 255.255.255.248"

    — Сеть поднялась, яндекс запинговался. Теперь обновляем дерево портов
    Дерево портов можно обновить с использованием утилиты portsnap или csup
    В нашем случае будем обновлять через portsnap. Для этого пишем команды:
    portsnap fetch, это загрузит полное дерево портов в каталог /var/db/portsnap
    portsnap extract, этой командой мы распакуем новое дерево портов в каталог /usr/ports

    После обновления портов имеет смысл заняться сборкой своего собственного ядра, хотя делать это не обязательно, ipfw, dummynet и pf можно подгрузить модулями, а на производительность пересобранное ядро особо не влияет. В нашем случае пересборка ядра нужна из за опции HZ, это интервал таймера. По умолчанию там стоит 100, что не очень подходит для больших скоростей, поэтому будем менять его на 2000

    Копируем дистрибутивный конфиг ядра в другой файл
    cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/router-001
    открываем файл router-001 текстовым редактором (vi, nano) и начинаем его править. После правки ядра под ваши нужды надо не забыть добавить в конфиг ядра следующие параметры:

    #ipfw firewall , этим мы будем шейпить пользователей
    options IPFIREWALL
    options IPFIREWALL_VERBOSE
    options IPFIREWALL_VERBOSE_LIMIT=100
    options IPFIREWALL_FORWARD
    options DUMMYNET
    options HZ=2000

    # pf, а этим мы будем NAT-ить локальные IP
    device pf
    device pflog
    device pfsync


    Далее командами make buildkernel и make installkernel мы собираем и устанавливаем ядро

    После сборки ядра переходим к настройке нашего файрвола ipfw
    В файл /etc/rc.conf добавляем следующие строки:
    firewall_enable="YES"
    pf_enable="YES"
    pf_rules="/etc/pf.conf"

    полностью очищаем файл /etc/rc.firewall и начинаем писать в него свои правила, ничего сложного нету так-так rc.firewall представляет собой самый обычный shell скрипт который запускается при старте ipfw

    строки которые добавляем в новый /etc/rc.firewall
    #!/bin/sh , указываем путь к командному интерпретатору

    /sbin/ipfw -q flush
    /sbin/ipfw -q pipe flush , очищаем правила файрвола и очереди dummynet при старте
    fwcmd="/sbin/ipfw -q" , Задаем путь к ipfw и опцию с которой запускаться. –q говорит файрволу о том, чтобы он не спрашивал подтверждения

    WAN_IP = 195.xxx.xxx.231, указываем основной IP адрес внешнего интерфейса
    IBGP_NET = 195.xx.xx.224/xx
    LAN_IP = 10.249.0.0/16 , указываем диапазон наших внутренних сетей

    ${fwcmd} add 10 allow ip from any to any via lo0 , задаем правило разрешающее все на
    loopback интерфейсe

    ${fwcmd} add 11 allow ip from me to me , разрешаем пакеты с этого хоста на этот хост

    ${fwcmd} add 12 allow icmp from any to me, разрешаем icmp на этот хост

    ${fwcmd} add 20 allow tcp from table(1) to me dst-port 22 , разрешаем подключаться к шейперу
    по протоколу ssh с IP адресов указанных в таблице 1. Занести адрес в эту таблицу можно
    командой ipfw table 1 add <ip_address>

    ${fwcmd} add 21 deny tcp from any to me dst-port 22 , окончательно запрещаем ssh. Под это
    правило попадут все, кто не в таблице 1

    ${fwcmd} add 30 pipe tablearg ip from any to table(2) out via em1
    ${fwcmd} add 31 pipe tablearg ip from table(3) to any in via em1 , выпускаем пользователей из таблиц 2 и 3 в интернет и указываем им конкретный пайп дамминета для шейпинга. Номер пайпа указываем при добавлении пользователя в таблицу, каждая таблица для определенного типа трафика (2 для входящего к клиенту, 3 – для исходящего). Добавление пользователя в таблицу происходит командами ipfw table 2 add <ip клиента> <номер пайпа> и ipfw table 2 add <ip клиента> <номер пайпа>

    Если вы хотите редиректить заблокированных пользователей, то необходимо будет добавить редирект на
    локальный веб-сервер (например nginx)
    ${fwcmd} add 38 fwd 127.0.0.1,3128 tcp $LAN_NET to not me dst-port 80
    ${fwcmd} add 39 allow tcp from any $LAN_NET src-port 80

    ${fwcmd} add 40 deny all from $LAN_NET to not me
    ${fwcmd} add 41 deny all from not me to $LAN_NET , блокируем пакеты к нашим сетям. Под эти правила попадут те пользователи которые отстутствут в таблице 2 и таблице 3

    ${fwcmd} add 50 allow ip from me to any keep-state , разрешаем полный доступ исходящим соединениям с этого сервера и сохраняем их состояние.

    ${fwcmd} add 51 allow tcp from $IBGP_NET to $WAN_IP dst-port 179 , разрешаем хостам находяшимся в vlan со внутренним BGP устанавливать с нами соединение на 179 порт (bgp протокол)

    ${fwcmd} add 52 allow ospf from 195.xxx.xxx.192/29 to any , разрешаем ospf с определенной сети
    Теперь мы задаем пайпы дамминета, собственно сам шейпинг
    Примерно вот так:
    #Speed 15Mbps, Для игр
    ${fwcmd} pipe 1 config mask dst-ip 0xffffffff bw 16000Kbit/s
    ${fwcmd} pipe 101 config mask src-ip 0xffffffff bw 16000Kbit/s

    #Speed 20Mbps, Для отдыха
    ${fwcmd} pipe 2 config mask dst-ip 0xffffffff bw 21000Kbit/s
    ${fwcmd} pipe 102 config mask src-ip 0xffffffff bw 21000Kbit/s

    #Speed 3Mbps, Для новичков
    ${fwcmd} pipe 3 config mask dst-ip 0xffffffff bw 3500Kbit/s
    ${fwcmd} pipe 103 config mask src-ip 0xffffffff bw 3500Kbit/s

    В любом случае правим все под себя (не забыва что пакет сначала попадет под действие ipfw, а только потом перейдет на обработку pf) в соответствии с данными рекомендациями, на этом файрвол считаем настроенным. В принципе если вы не хотите использовать tablearg, то можно и не использовать. Есть еще варианты по pipe на клиента или по отдельной таблице на тариф. Эти варианты я не рассматриваю, в связи с высокой нагрузкой на оборудование (pipe на клиента) и неудобством (таблица на тариф)

    Для полноты картины осталось только настроить NAT, который мы будем делать через pf.
    Создаем файл /etc/pf.conf и вписываем в него следующие строки

    WAN_IF=«em0», это наш внешний интерфейс в влане со внутренним bgp. Именно на нем мы будем производить NAT

    LOCAL_NET=«10.249.0.0/16», это диапазон нашей локальной сети который будем NATить

    nat on $WAN_IF from $LOCAL_NET to! $LOCAL_NET -> ($WAN_IF) round-robin sticky-address, а это само правило для NATа из внутренней сети на вшеншний интерфейс
    параметр round-robin означает использование адресов пула по кругу.
    параметр sticky-address используется для гарантии назаначения всегда одного и того же адреса источника в адрес пула.

    Теперь приступаем к настройке пакета quagga
    От него нам нужна поддержка bgp и поддержка ospf в моем случае

    Zebra.conf я публиковать не буду, в нем все просто и однотипно. Описываем интерфейсы и статические маршруты, вот вырезка из него:

    interface em0
    ip address 195.xx.xxx.231/xxx
    description ibgp
    !
    interface em1
    ip address 195.xxx.xxx.193/29
    description ospf
    !
    ! Static routes.
    !
    ip route 10.0.0.0/8 Null0 254
    ip route 79.142.80.132/30 195.xxx.xxx.238
    ip route 94.124.180.57/30 195.xxx.xxx.225


    Приводим конфиг bgp примерно вот к такому виду. Т.е принимаем маршрут по умолчанию от пограничных маршрутизаторов и отдаем ему какие-либо специфичные маршруты

    hostname gw2.xxx.ru
    password rxxxx
    enable password rxxxxx
    log file /var/log/quagga/bgpd.log
    !
    router bgp 3333
    bgp router-id 195.xxx.xxx.231
    bgp log-neighbor-changes
    network 195.xxx.xxx.192/29
    neighbor 195.xxx.xxx.225 remote-as 3333
    neighbor 195.xxx.xxx.225 description j4350-1
    neighbor 195.xxx.xxx.225 next-hop-self
    neighbor 195.xxx.xxx.238 remote-as 3333
    neighbor 195.xxx.xxx.238 description j4350-2
    neighbor 195.xxx.xxx.238 next-hop-self
    !

    Далее мы настраиваем протокол OSPF (используется в моем случае, так-как параллельно Cisco Catalyst 3560 установлен Dlink DGS-3612)

    Hostname gw2.xxx.ru
    password xxx
    enable password xxxx
    log file /var/log/quagga/ospfd.log
    !
    interface em1
    !
    router ospf
    ospf router-id 195.xxx.xxx.193
    network 195.xxx.xxx.192/29 area 0.0.0.0
    default-information originate metric 100
    !
    line vty


    Если у вас стоит коммутатор который умеет работать с BGP, то лучше отказаться от использования OSPF и использовать для этих целей протокол BGP. В таком случае в
    bgpd.conf надо внести следующие строки

    neighbor 195.xxx.xxx.195 remote-as 3333
    neighbor 195.xxx.xxx.195 description sw-c3560-xxx.ru
    neighbor 195.xxx.xxx.195 default-originate


    Вроде все настроили, теперь главное не забыть небольшой тюнинг sysctl
    Добавляем в существующий /etc/sysctl.conf следующие строки
    net.inet.ip.forwarding=1 #разрешаем пересылку пакетов между интерфейсами
    net.inet.ip.fw.one_pass=1 #разрешаем однопроходный режим ipfw
    net.inet.icmp.bmcastecho=0 #не отвечаем на пинг на широковещательный адрес
    net.inet.tcp.blackhole=2 #отбрасываем пакеты на закрытый порт (не слушаемый никем)
    net.inet.udp.blackhole=1 # отбрасываем пакеты на закрытый порт (не слушаемый никем)
    net.inet.ip.dummynet.io_fast=1 #новое поведение dummynet( шейпирование канала)
    net.inet.icmp.drop_redirect=1 #дропаем icmp редиректы
    net.inet.icmp.log_redirect=1 #пишем icmp редиректы в log, бывает полезно
    net.inet.ip.redirect=0 # если 0, то нет реакции на ICMP REDIRECT пакеты
    net.inet.ip.dummynet.expire=0 # в случае кратковременного прекращения трафика пользователя не
    #выносим его из очереди
    net.inet.ip.dummynet.hash_size=16384 # размер хэш-таблицы, используемой dummynet для
    #хранения очередей. Увеличение этого значение ускоряет работу
    #dummynet при большом #количестве очередей, естественно в
    # обмен на оперативную память


    На этом наш шейпер считаем законченным, я заранее опустил интеграцию его с биллинговой системой, так как у каждого свое и свои методы
    Можно смело писать команду reboot и если все было верно настроено то можно приступать к настройке коммутатора 3-го уровня (l3)

    А если мы еще хотим переадресовывать пользователей которым не разрешен доступ в интернет на определенную страницу с информацией о блокировке, то ставим веб сервер nginx и пишем ему в конфиг (nginx.conf) следующий текст

    user nobody;
    worker_processes 2;
    events {
    worker_connections 1024;
    }
    http {
    include mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 35;
    server {
    listen 3128;
    server_name wkt_router;
    charset windows-1251;
    access_log /dev/null;
    rewrite ^(.*) blocked.wktnet.ru/index.htm permanent;
    }
    }

    Настройка коммутатора 3-го уровня

    В моей сети используется Cisco WS-C3560G-24-TS-S, там все просто
    Заходим в режим конфигурирования: conf t
    Присваиваем IP адрес интерфейсу vlan-а внутри которого бегает ospf, (та-же сеть что на шейпере на интерфейсе em1)
    И настраиваем ospf

    router ospf 1
    router-id 195.xxx.xxx.195
    log-adjacency-changes
    network 10.249.33.0 0.0.0.255 area 0.0.0.0
    network 10.249.42.0 0.0.0.255 area 0.0.0.0
    network 10.249.51.0 0.0.0.255 area 0.0.0.0
    network 10.249.55.0 0.0.0.255 area 0.0.0.0


    сохраняем конфиг командой wr и радуемся достигнутому результату

    если вместо протокола ospf вы решили использовать bgp то в конфиг коммутатора необходимо добавить следующие строки

    router bgp 3333
    bgp log-neighbor-changes
    network 10.249.33.0 255.255.255.0
    redistribute ospf 1
    neighbor 195.xxx.xxx.193 remote-as 3333
    neighbor 195.xxx.xxx.193 description gw


    Если у вас используется l3 коммутатор D-link, то на нем настраиваем OSPF следующими командами

    enable ospf, включаем ospf на коммутаторе
    config ospf router_id 195.xxx.xxx.196, указываем id роутера
    config ospf ipif <интерфейс> area 0.0.0.0 state enable, включаем ospf на интерфейсе

    и сохраняем конфиг командой save

    Настройка резервного сервера

    На соседнем (резервном шейпере) мы производим аналогичную настройку, за исключением конфига ospf и IP адресов
    Отличие в том, что default-information originate мы задаем метрику 200, тогда он становится резервным. Хотя можем оставить метрику 100 и получить балансировку нагрузки между шейперами, но в своей сети я этот вариант не использую так как при такой настройке клиенты получат двойную скорость (по тарифной скорости на каждом шейпере).

    Заключение

    В итоге мы получаем систему с динамической маршрутизацией (в случае отказа одного из шейперов или пограничных маршрутизаторов мы автоматически начинаем использовать соседний, все маршруты сети прописанные на коммутаторах 3-го уровня автоматически появляются в таблице маршрутизации на наших шейперах). Если вас пугает мысль о простаивающем сервере, то можете поиграться с настройками, сменить ospf на bgp, поставить еще один L3 коммутатор и выпускать часть сети через него.

    Схема получившегося узла:
    image

    Для примера приведу свой rc.firewall

    cat /etc/rc.firewall
    #!/bin/sh
    #Flush all firewall rules
    /sbin/ipfw -q flush
    /sbin/ipfw -q pipe flush
    #Setting firewall path and options for working with rules
    fwcmd="/sbin/ipfw -q"
    #variables
    IBGP_NET="195.93.xxx.xxx/28" #iBGP network (vlan9)
    WAN_IP="195.93.xxx.xxx" #Primary WAN ip address
    LAN_IP="195.93.xxx.xxx" #Primary LAN ip address

    ###System rules
    ${fwcmd} add 10 allow ip from any to any via lo0 #do not filter loobpack
    ${fwcmd} add 11 allow ip from me to me #allow packets from this host to this host
    ${fwcmd} add 12 allow icmp from any to me #allow ICMP

    #allow ssh connections
    ${fwcmd} add 20 allow tcp from table\(6\) to me dst-port 22 #Allow SSH connections (table 6)
    ${fwcmd} add 29 deny tcp from any to me dst-port 22

    #allowing users and add his ip to shaping pipe
    ${fwcmd} add 30 pipe tablearg ip from any to table\(1\) out via em1
    ${fwcmd} add 31 pipe tablearg ip from table\(2\) to any in via em1

    #Block spammerss
    ${fwcmd} add 34 deny ip from table\(3\) to any dst-port 25 #for auto block spammers

    #allow connections to this networsk
    ${fwcmd} add 40 allow all from table\(7\) to any
    ${fwcmd} add 41 allow all from any to table\(7\)

    #allow active users
    ${fwcmd} add 45 allow all from not me to table\(1\)
    ${fwcmd} add 46 allow all from table\(2\) to not me

    #By default block users
    ${fwcmd} add 48 fwd 127.0.0.1,3128 tcp from table\(8\) to not me dst-port 80
    ${fwcmd} add 49 allow tcp from any to table\(8\) src-port 80
    ${fwcmd} add 50 deny all from table\(8\) to not me
    ${fwcmd} add 51 deny all from not me to table\(8\)

    ###Access rules
    #allow outgoing connections
    ${fwcmd} add 60 allow ip from me to any keep-state #allow all ougoing packets and keep state

    #Rules allowing SNMP
    ${fwcmd} add 61 allow udp from table\(6\) to $WAN_IP dst-port 161 #Allow SNMP

    #Rules allowing bgp
    ${fwcmd} add 64 allow tcp from $IBGP_NET to $WAN_IP dst-port 179 #Allow BGP from iBGP network (vlan 9)

    ###############################################заполняем таблицы
    #таблица 6 - это те кто имеют доступ к маршрутизатору по ssh,telnet и snmp
    ${fwcmd} table 6 add 195.93.xxx.xxx #wkt office
    ${fwcmd} table 6 add 89.xxx.xxx.1 #
    ${fwcmd} table 6 add 93.xx.xxx.xxx #

    #таблица 7 - IP адреса и сети с доступом при выключенном интернете
    ${fwcmd} table 7 add 195.xxx.xx.0/25 #binat
    ${fwcmd} table 7 add 195.xx.xx.0/26 #servers dmz
    ${fwcmd} table 7 add 195.xx3.xx.192/29 #int net
    ${fwcmd} table 7 add 195.xx.xxx.xxx #c3560-b51
    ${fwcmd} table 7 add 10.88.88.1
    #таблица 8 - это наши локальные сети внутри которых пользователи
    ${fwcmd} table 8 add 10.87.0.0/16
    ${fwcmd} table 8 add 10.88.0.0/16
    ${fwcmd} table 8 add 10.249.0.0/16
    ${fwcmd} table 8 add 10.90.0.0/16
    ${fwcmd} table 8 add 195.93.xxx.0/25
    ${fwcmd} table 8 add 195.93.xxx.128/25
    ${fwcmd} table 8 add 195.93.xxx.64/26
    ${fwcmd} table 8 add 195.93.xxx.200/28

    #таблицы 1 и 2 - это пользователи и их тариф
    ##WKT tech
    ${fwcmd} table 1 add 10.87.xx.250/32 55
    ${fwcmd} table 2 add 10.87.xx.250/32 255
    ${fwcmd} table 1 add 10.87.xx.251/32 55
    ${fwcmd} table 2 add 10.87.xx.251/32 255


    И bgpd.conf

    hostname gw2.xxxx
    password rxxxx
    enable password xxx
    log file /var/log/quagga/bgpd.log
    !
    router bgp 44xxx
    bgp router-id 195.93.xxx.xxx
    bgp log-neighbor-changes
    network 195.93.2xx.xxx/29
    neighbor 195.93.206.xx remote-as 44380
    neighbor 195.93.206.xx description j4350-b51
    neighbor 195.93.206.xx next-hop-self
    neighbor 195.93.206.xx remote-as 44380
    neighbor 195.93.206.xx description j4350-k18
    neighbor 195.93.206.xx next-hop-self
    neighbor 195.93.206.xx remote-as 65000
    neighbor 195.93.206.xxdefault-originate
    neighbor 195.93.206.xx description sw-c3560g-24ts-b51
    neighbor 195.93.206.xx route-map c3560g-b51-in in
    neighbor 195.93.206.xx remote-as 65001
    neighbor 195.93.206.xx default-originate
    neighbor 195.93.206.xx description sw-c3560g-24ts-k18
    neighbor 195.93.206.xx route-map c3560g-k18-in in
    !
    route-map c3560g-k18-in permit 10
    set local-preference 200
    !
    route-map c3560g-b51-in permit 10
    set local-preference 300


    UPD: для того чтобы прописать в /boot/loader.conf kern.hz=«2000» не обязательно пересобирать ядро.
    Поделиться публикацией

    Похожие публикации

    Комментарии 78

      +3
      А если умрет l3 switch?
        +2
        Ну Л3 свитч ставится обычно не один, а несколько :) по 12 домов на него цепляется. Да и можно с VRRP поиграться
          0
          Мне статья пришлась очень по душе.
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              кстати по оспф-у там косяки у меня. можно было не прописывать
              в router ospf 1
              network
              а сделать redistribute local.
              статья и куски конфигов в ней очень старые)
                +1
                Не получится. Если не писать network то в этой сети (на этом линке) ОСПФ не заведется.
                  0
                  router ospf 1
                  router-id 172.16.48.32
                  log-adjacency-changes
                  redistribute connected metric 2 subnets
                  redistribute bgp 65000 metric 4 metric-type 1 subnets
                  network 10.249.0.8 0.0.0.3 area 0.0.0.0
                  default-information originate metric 100
                  !

                  я имел ввиду примерно вот такую конфигурацию :)
                    0
                    Ну а я имел ввиду, что совсем отказаться от
                    network 10.249.0.8 0.0.0.3 area 0.0.0.0
                    не получится. Правда есть способ не анонсировать служебную сеть
                    10.249.0.8/30

                    Надо написать
                    network 10.249.0.8 0.0.0.0 area 0.0.0.0

                    Тогда ОСПФ на интерфейсе поднимется, но сеть /30 анонсироваться не будет.
                      0
                      Не обязательно перечислять все сети в network, если у вас софт выше чем 12.3(11)T.
                      Можно воспользоватся командой ip ospf ID area Area_ID, в контексте интерфейса.

                      Я пробовал здесь — techoover.blogspot.com/2008/05/vpn-ospf-over-gre-ipsec.html
                +1
                Реализация интересная, как решается кого как шейпить?
                При новых тарифах переписывать шейпер?)
                  0
                  все скорости тарифов как и добавление и удаление из таблиц используем самописным модулем, поэтому для изменения скорости тарифа на всех маршрутизаторах достаточно поправить циферки в веб интерфейсе :)
                  +2
                  для того чтобы прописать в /boot/loader.conf
                  kern.hz=«2000»
                  не обязательно пересобирать ядро.
                    0
                    хм. спасибо, вот про это не знал
                    0
                    Мощная статья. Но читается довольно трудно: я плохо разбираюсь в *нике, кто-то — в циске, кто-то в задачах полной избыточности.

                    У меня возник ряд вопросов: сервера (шейперы) стоят в-основном для связи с биллинговыми приложениями? Что используется для биллинга? Как считается трафик?

                    ПО какому принципу шейпите? Почему это нельзя сделать на 3560?

                    ИМХО, для ядра коммутации стоило бы поставить хотя бы парочку 3750 в стеке. Как раз для этого придумано.

                    Вы используете одновременно 2 канала? Как решается проблема с НАТ трансляциями? Трансляции делают шейперы, насколько я понял? А почему не сделать на Джуниперах? Они поддерживают stateful NAT?
                      0
                      А как на 3550/3560 сделать шейп для конкретного IP-адреса?
                      И не rate-limit возможно, а именно shape с очередью.
                        0
                        имел ввиду на порту. При ШПД очень часто клиент=интерфейс коммутатора.
                          0
                          Кстати, провайдеру скорее нужно делать не шейпер, а полисер (резать жестко, а не «в среднем»), иначе не ровен час — будут постоянные перегрузки железа.
                            0
                            при не очень широких полосах шейпер будет лучше.
                            во-первых, при загрузке канала на полную клиентом он будет наблюдать заметные потери пакетов, во-вторых, много трафика, предназначенного клиенту будет доходить до шейпера, загружая внешний канал.
                              0
                              WRED + policer на UDP?

                              Вам виднее — я не провайдер. Просто мне интересно, для пополнения собственной копилки решений.

                              Собсно, вскорости надо будет выползать из cisco-only решений, отсюда и интерес.

                              А вы предоставляете доступ по езернету? И при этом тарифы примерно как на АДСЛе?
                                +1
                                Да, предоставляем доступ по езернету.
                                Шейпим на FreeBSD, раньше использовали ipfw pipe (queue + GRED), теперь переползли на ng_car, для небольших полос shape, для больших — rate-limit.
                                Недавно пытался настроить полисинг на 3550 для одного из клиентов, был разочарован.
                                  0
                                  Да, на 3550 довольно грустный QoS.

                                  С другой стороны циска позиционирует только маршрутизаторы, как наиболее богатую механизмами QoS платформу. А свитчрутеры туда в полном объеме не входят (65хх не беру)
                              0
                              ам… вообще «шейпить или полисить?» тонкий такой вопрос с кучей там всяких обстоятельств :( но есть о чем подумать, да. :)
                            0
                            Для биллинга используем дописанный UTM5, все скорости тарифов как и добавление и удаление из таблиц используем самописным модулем, поэтому для изменения скорости тарифа на всех маршрутизаторах достаточно поправить циферки в веб интерфейсе :) 3560 занимаются коммутацией и маршрутизацией пирингового и локального траффика, поэтому нарезание полос на нем не совсем уместно. Да одновремено используется два канала, весь NAT осуществляется прямо на шейперах. NAT на джуниперах не используем в связи с тем, что тупо не справятся при текущих потоках траффика
                              0
                              Не работал с UTM5 — он каким стандартом на вход данные требует? НетФлоу поддерживает?

                              Получается, что Джуниперы эти — совсем дохлые? Странно: НАТ не более нагруженная операция, чем маршрутизация. Во всяком случае у меня циски валились от НАТа только когда сеть цепляла червя.

                              шейпите по адресу источника, т.е. коммутационная сеть работает на скоростях выше тарифных. Перегрузок нет?

                              А как вы добиваетесь, чтобы пользователя не видели друг друга? PPTP? PPPoE?
                                0
                                Нетфлоу умеет, им и сливаем все с шейперов. Не, через джуниперы траффика много льется + несколько бгпфулвью.
                                Шейпим по адресу источника и по адресу назначения. А зачем добиватся чтобы юзеры друг друга невидели?) Нет такой нужды, предоставляем абонентам полный доступ к локальной сети и соседним операторам которые с нами в пиринге на скорости порта (до 100мбит/с), единственное что на уровне доступа ограничиваем — это режем броадкаст и нетбиос, вещание мультикастом и привязываем с помощью ACL выданный IP адрес абоненту на его порт
                                  +1
                                  А чем рулите такое кол-во ACL? Получается, что у вас все порты — L3? Или вы делаете vlan access-map?

                                  Просто интересно.

                                  Пользователей обычно делят (и я тоже небольшим провайдерам когда рисую картинки рекомендую) дабы не было беды, когда одна зараженная машина легко заражает соседей и в итоге лежит вся сеть и компы все болеют. Мне было бы неприятно обнаружить заразу на компе и отсутствие Инета :)
                                  Я понимаю и плюсы: все всех видят, игрухи там, файлопомойка… Но ИМХО, так уже делать просто опасно. Я обычно рекомендую провайдерам (как правило, уже хлебнувшим :)) делать полноценный ДМЗ, с общими сервисами. МОжно за денеШку пользователям выделять там квоты, сервисы и пр. А хотят пириться — е-муль им в помощь :)
                                    0
                                    не. vlan access-map делать не можем) на доступе используем Dlink DES-3526 и его весьма неплохие возможности. Ставить каталисты на доступ к физлицам — недешевое удовольствие да и совсем бесполезное а случаи с флудом или вирусными эпидемиями много беды не приносят, по крайней мере не затрагивают всех пользовалей. На каждый дом делаем свой отдельный влан
                                      0
                                      Я все же не понял, что и где фильтруется при помощи ACL?

                                      И про деление пользователей: понятно, что каждому свою сеть — плохо, каждому свой ВЛАН — можно, но накладно. Но есть ещ технология private vlan, а также её дешевый аналог — protected ports.

                                      Используя port protected все юзвери в одном ВЛАНе в рамках коммутатора, но видят только гейтвей и то, что вы явно разрешите.
                                        0
                                        Dlink DES-3526 имеет достаточно вменяемые возможности по фильтрации. К администратору эти ACL повёрнуты «другим лицом», но работают вполне прилично.
                                      +1
                                      Если уж пользователей делить — то надо делить совсем, т.е. — каждому по VLAN'у. А это уже совсем другие деньги и на уровне доступа, и на агрегации, и в ядре…
                                      А если хочется сэкономить и убрать локал с ядра, то тогда уж лучше действительно выпустить всех в один большой L3-сегмент, но порезать на уровне L2 все потенциально опасное. К этому уже пришли многие большие операторы (та же Корбина в Москве), я у себя на сети делал также: около 3 с половиной тысяч человек в одной L3-сети чувствовали себя совершенно нормально. Современные железки L2 позволяют нормально зафильтровать все, чем могут пользователи повредить друг другу (автор комментарием выше тоже пишет — бродкаст, нетбиос и т.п.)… По крайней мере у меня никаких проблем не было…
                                      А делить клиентов на отдельные L3-подсети в целях борьбы с вирусней и так далее — это уже прошлый век…
                                        0
                                        Угу. про что я и говорю, но имхо все-же еще стоить бить сеть на вланы. По влану на дом — самое то, а на агрегации держать Л3 коммутаторы для терминации домовых вланов. Делать один влан на 3к юзером имхо чревато, хотя доводилось работать и с такими сетями и оно прекрасно работало и работает до сих пор :)
                                          0
                                          А чем чревато? :-) ИМХО, это просто инстинктивный срах из дремучих глубин подсознания. :-) Я вначале тоже боялся, а потом — нормально… :-)
                                          0
                                          см ответ топикстартеру: private vlan

                                          Я с трудом себе представляю, как порезать на L2 многие бяки. Броадкаст с мультикастом — довольно легко. А торренты/скайпы/сервера? Часто и такая задача ставится (правда скорее не в домовых сетях, тут я до кучи написал :))
                                            0
                                            Неее… Все эти private vlan, как бы они у каждого вендора ни назывались, — это все костыли. Либо от бедности, либо от неумения настроить все нормально на уровне доступа. Т.е. сколько-то лет назад смысл был: можно было покупать дешевые коммутаторы на доступ (у которых нет ничего, только private vlan), а резать все где-нибудь на агрегации. Но сейчас такой проблемы с оборудованием нет и взять на доступ нормальную полнофункциональную железку, которая сразу все и порежет — вполне реально. Уже несколько лет как… Т.е. это все, конечно, мое личное мнение, а не истина в последней инстанции, но я действительно не вижу смысла грузить локалом агрегацию и ядро, когда есть возможность по сути на те же деньги разрулить его там же на доступе…

                                            Во-первых, давайте все-таки разделять распределенные ethernet-сети (т.е. пресловутые «домовые») и корпоратив. В корпоративе совсем другие требования и совершенно иная специфика. Там, по-моему, VLAN на пользователя — это вообще единственный вариант с моей точки зрения. :-)
                                            А во-вторых, «многие бяки» тоже надо разделять. Если мы говорим о фильтрации по адресам/портам/протоколам — это без проблем. На L2 уровне фильтровать по заголовкам IP сейчас умеют любые китайцы, не говоря уже о более серьезных людях. Вопрос же фильтрации по контенту — он зачастую и софтовыми вещами в ядре не вполне успешно решается, не то что железом на уровне доступа… Но с другой стороны у того же Длинка уже много-много лет есть Packet content filtering, который вообще по любому содержимому пакета фильтрует — возможности открываются по сути безграничные. :-) Не в курсе — может уже кто-то еще успел у себя это внедрить… Какая-нибудь EdgeCore или типа того… Если внедрили, то вообще шоколадно — а то очень многие выбирают ДЛинки именно из-за этой фичи…
                                              0
                                              Семантика ACL фильтрации DES3526.

                                              Создаётся профиль ACL в котором определяется какие байты будут сравниваться в Ethernet кадре. Определяется отступом (offset) от начала Ethernet кадра. Возможно указать любой набор байт в диапазоне от 0 до 79.

                                              Создаётся правило из профиля и конкретные значения байтов, набор которых указан в профиле, а так же порты коммутатора, к которым применяется данное правило ACL

                                          0
                                          ахахаха Ж)) на софтой J-series снимаете netflow sampling? :D они ведь по-другому не умеют. да и железку ушатываете не понять чем ) и да, как на это все смотрят метрологи, когда вы билленгуете по скажем каждому 100ому пакету? есть сертификат и бумажки? :)

                                          0
                                          > Получается, что Джуниперы эти — совсем дохлые? Странно: НАТ не более нагруженная операция, чем маршрутизация. Во всяком случае у меня циски валились от НАТа только когда сеть цепляла червя.

                                          ойли? а что тогда 7200 + npe-G2 при нате ласты заворачивает? да чо уж нат, она и при обычном форвардинге ласты завернет гораздо раньше чем до гигобита доживет.

                                          странно вообще от тебя слышать про нат такое. Оо

                                          вообще маршрутизация выполняется на cef, что есть на любом cisco router'е или почти на любом. netflow export выполняется почти там же, поэтому утилизация при netflow export'е почти не меняется. а вот операция nat'а выполняется софтварно, т.е. на процессоре. или просто так спицально для nat'ов продают ace модуль за кучу денег для 6500-7600 решений?

                                          данные «жуниперы» относятся к линейке J-series, что есть вобщем-то офисные маршрутизаторы, точнее фиреволы. по-умолчанию с junos 9.Х они работают во flow-based режиме и превращаются в пакетный маршрутизатор путем добавления нескольких магических комманд и переводом в packet-based режим. они целиком софтовые, т.е. и менеджмент устройства и форвардинг выполняется на _одном_ процессоре. да и если посмотреть во внутирь будет виден обычный писюк с целероном 2.5ГГц на борту :) однако, если нет желание маршрутизировать более гигобита трафика, то J-series очень вкусное решение. но, конечно, семплить с него нетфлоу или резать полисерами трафик на несколько тысяч абонентов при этом странная затея, примерно такая же как и натить при помощи cisco 7200 + npe-G2 :)
                                            0
                                            хм. да, cisco сама заявляет что мол падением производительности при nat'е можно принебречь. мол так оно мало. ( www.cisco.com/en/US/tech/tk648/tk361/technologies_q_and_a_item09186a00800e523b.shtml#qa7 )

                                            однако, мой опыт говорит о весьма заметном снижении производительности при nat'е. :(
                                              0
                                              Ты прям как порох :)

                                              Я ведь в Жуниперах — сам знаешь, поэтому в вопросе ключевым словом было эти :)

                                              НАТ сам по себе не очень жруч. Особенно если записи не слишком часто меняются. Память да, могут откушать. Но поиск соотв. правила в конфиге и применение — не сумасшедшая нагрузка. ip input съедает почти 100% по НАТу только при червивом заражении: там МАССА сессий полуоткрытых создается. И циске (как и любой железке) становится трудно
                                        +1
                                        Проглядел статью мельком, так что возможно что-то не до конца вкурил… Вообще, имхо, статью бы лучше на несколько разбить, а то букв слишком много…
                                        Что используете таблицы и tablearg для шейпинга в ipfw — это хорошо (в инете до сих пор много старых мануалов со старыми конфигами, от которых плакать хочется), но зачем вам pf? Советую: переходите на ядерный ipfw nat, который появился в семерке. Все функции libalias (а значит по дефолту — нет необходимости ковыряться, например, с проксирование активных ftp, т.к. все это работает из коробки), отсутствие необходимости городить лишний огород и к тому же — существенный прирост производительности. Какую полосу вы шейпите и НАТите? Еще около года назад (когда я работал в телекоме :-) ) я как раз решал все эти вопросы и после профилирования через hwpmc убедился, что pf тормозит — дай Боже! Вот здесь подробнее: forum.nag.ru/forum/index.php?showtopic=47497
                                        pf — это вообще файрволл для домохозяек. :-) Если надо побыстрому выпустить в инет офис и есть время только для написания двух строчек — альтернативы pf отсутствуют. :-) Но для серьезного провайдинга — это все фигня. К тому же он на несколько процессоров не раскладывается до сих пор по-моему…
                                        В общем, мой вам совет — откажитесь от pf и перейдите полностью на ipfw. Серверу сильно полегчает и избавитесь от костылей (от тех же дополнительных прокси для активного FTP). :-)
                                          0
                                          А ядерный ipfw nat уже достаточно отлажен? Все на pf из-за того, что боязно до сих пор переходить. Как оно себя поведет при траффике 300мбит/с в обе стороны (суммарно 600) и 100к pps? pf справляется, но действительно — нагрузка на железо не радует
                                            0
                                            > А ядерный ipfw nat уже достаточно отлажен?

                                            Зачем вы пользуетесь FreeBSD, если не доверяете STABLE? ;-) В этом же и бонус Бзди по сравнению с Линуксом: можно практически не тратить свое время на исследования надежности и тупо довериться мантейнерам. :-)
                                            Так вот, все с ipfw nat в порядке — проверено на личном опыте. Или ng_nat можете попробовать, если нетграф препочитаете — он даже дольше в порядке, чем ipfw nat. :-)

                                            > Как оно себя поведет при траффике 300мбит/с в обе стороны (суммарно 600) и 100к pps?
                                            Есть мнение, что поведет лучше, чем pf. У меня трафик был поменьше — порядка 400мбит суммарно и 75kpps, но и комп похуже был — Атлон какой-то…
                                            Ну и в любом случае, на таких объемах уже и ядро тюнить надо… У вас, кстати, эта тема, ИМХО, не до конца раскрыта. Например, сказано, что используются карточки Intel, а переменных в sysctl вы по ним никаких меняете… А там ведь можно подкрутить и загрузку по прерываниям уменьшить сильно… Ну это я уже так — побрюзжать. :-)
                                            0
                                            Что касается поддержки многопроцессорности/многоядерности ipfw то же довольно грустен. По крайней мере dummynet в 7.2 напрочь незнает про такую радость. Держим 5500килохомячков. Один внешний канал на котором freeBSD, шейпинг(табличка на тариф), нетфлоу и фулвью. Некоторое время был гигабитный канал наверх, но железка выжала только 400-500. dummynet съел 100% одного ядра а остальные 7 стояли в idle.
                                            Посему сижу познаю дао netgraph и мечтаю о больших кошках и джуниперах.

                                            Железо к слову 2хXeno E5420… 2500 MHz
                                              0
                                              Да, dummynet был и пока остается одноядерным… Это печально.
                                              Но вы уверены, что у вас именно dummynet выжрал? Вообще сам по себе он много жрать не должен — NAT больше жрет. Проглядел сейчас maillist'ы — все пишут, что 400-500 — это для dummynet'а семечки. Может, настроено чего неправильно было? io_fast было включено? Попробуйте профилировать ядро через hwpmc — сможете посмотреть, кто реально процессор жрет.
                                              Кошки и Жуниперы — на самом деле не панацея…
                                              Вообще, по тематике работы высоконагруженных шейперов и НАТов некоторое время назад были шикарные статьи на Наге. Шикарность прежде всего в том, что сравнивается большой спектр разного железа с указанием конкретных названий, что обычно редкость. Почитайте, если не видели:
                                              nag.ru/news/17045/
                                              nag.ru/news/17443/
                                                0
                                                вам можно посоветовать внедрить балансировку шейперов.
                                                т.е. выделить шейпинг на две отдельные машины и балансировать через них трафик.
                                                способов — куча. у меня балансировка сделана на втором уровне с помощью etherchannel, src-ip.
                                                  0
                                                  Про много шейперов как раз сейчас и думаю… только балансировку задумал на bgp. Кошек для etherchannel у меня нетю (
                                              0
                                              Немасштабируемо :(
                                                0
                                                А что по вашему мнению стоит поправить? И в какую сторону? Опишите свое решение, лично мне очень интересно
                                                0
                                                /me статью в закладки
                                                  0
                                                  wkt спалился
                                                    0
                                                    Конкуренты с унтолово, где мы спалились? )
                                                      0
                                                      server_name wkt_router;
                                                      charset windows-1251;
                                                      access_log /dev/null;
                                                      rewrite ^(.*) blocked.wktnet.ru/index.htm permanent;
                                                      


                                                      вот тут спалился…
                                                        0
                                                        и что?:) эта информация не является коммерческой тайной :)
                                                          0
                                                          согласен, кстати а в чем такие красивые картинки рисуешь?
                                                            0
                                                            стыдно говорить, но MS Visio (
                                                              0
                                                              действительно стыдно должно быть!
                                                              коллега )
                                                      0
                                                      пиринг не хотите поднять? :)
                                                      0
                                                      За что я люблю хабр, так это за то, что к статье, в которой я не нашёл и десятка знакомых слов, уже 44 комментария с дельными советами автору! Писец… ЧСВ втоптано в плинтус))
                                                        0
                                                        кстати, а вы пиринг поднять не хотите?
                                                          0
                                                          сп своего пока хватает
                                                          0
                                                          унылая статья, унылая концепция границы и ядра спд :( таких затейников-домушников полроисси. и да, два фиревола — это пять. вобщем дальше я не осилил прочитать. :(

                                                          впрочем ладно, кто во что горазд, тот так и строит. :(

                                                          бай зэ вей, мне вот очень интересно, в каком месте вы тут производите учет проданных абонентам услуг?
                                                            0
                                                            Рассказывайте свою концепцию и как предлагаете :) А почему вам не понравилось то что файрвола два?
                                                              0
                                                              потому что с одной стороны кто-то там плачется что с производительностью плохо, а с другой стороны никого не смущает гонять трафик через два фиревола и ожидать при этом чудес. :)

                                                              я понимаю что в pf altq'ой не порежешь как думминетом по маске пер ойпи таблицу из префиксов парой строчками в конфиге, но раз был сделан выбор на ipfw + dummynet, то почему нельзя было использовать тогда уж ng_nat, которые уже наверно как вечность стабилен и готов к использованию (да-да, иногда что-нибудь ломают в нем, но если не жить на блейд-эдж технологий, то все будет успешно работать). во freebsd кстате есть тьма ядерных натов, большая часть из которых умеет работать с ipfw :) помимо ng_nat сюда можно отнести и ipnat от анахронизма в виде ipfilter. к тому же, до недавненго времени во freebsd pf nat не умел gre через себя пускать, а с ftp он так и не дружит особо. держит ftp-proxy или как его на лупбаке?

                                                              кстате, сам по себе pf и его nat, и его шейпер весьма и весьма шустры. возможно шустрее и ipfw. тут какбэ я не очень хочу разжигать холивары между любителями ipfw и pf. но вот как-то так, да.

                                                              а главная унылость схемы заключается в концепции резервирования. например, почему на каждом 4350 именно по отдельному аплинку? что, при необходимости проапгрейдить на одном из них junos будете опускать целиком весь аплинк? чем это все аргументировано? отстутвием пары килобаксов на память для 4350 чтобы уместить пару таблиц full-view в него? т.е. какбэ получается при выходе из строя всего лишь одного из 4350 мы теряем и маршрутизатор и второй аплинк. :( имхо не очень хорошо.

                                                              далее, ваша схема и приведенные конфиги противоречат друг другу, что из них правильно? если схема, то получается совсем все печально. зачем вам фуллвью, если выбор маршрута все равно выбирается на основании наличия дефолтного префикса от писюковых натошейперов? т.е. фактически сравнения всей фуллвью по атрибутам бгп и выбора наилучших маршрутов между двумя таблица от двух провайдеров не происходит. зачем тогда это все нужно?

                                                              мне кажется надо чуть лучше все таки готовиться и писать такие статьи, ну или хотя бы понимать о чем идет речь.

                                                              пс: и да, поллинг не есть хорошо. на хорошие сетевые карты опять же не хватило денег или не хватило терпения докрутить гайки в sysctl?
                                                              ппс: все эти писироутиры — это все как-то не айс :) cisco isg — вот это айс :)
                                                                0
                                                                > например, почему на каждом 4350 именно по отдельному аплинку?

                                                                вычитал в комментах что таке не по отдельному. ну да ладно. :(
                                                                  0
                                                                  сленга многовато. Похоже автор (ты) пытаешься скрыть что-то :)

                                                                  Либо неумение писать правильно (гигабайт), либо «плаванье» в теме :)

                                                                  ЗЫ Это в твоем стиле написанное замечание :)
                                                                    0
                                                                    если речь про гигОбайт или гигАбайт, то не придерайтесь. если речь о том что я путаю биты с байтами, то покажите где. вроде не путаю, может очепятался :(

                                                                    насчет информации, ну блин, я же не статью пишу :) я так, в камментах ерундой страдаю :) вовсе не значит что то что я говорю это догматичная истина. :(
                                                                      0
                                                                      да, вы правы Ж) я всегда много не договариваю, так, только по верхушкам скачу :) могу и договорить, но тогда это потянет на отдельную статью, а ее писать, проверять орфографию и прочей ерундой заниматься у меня особо желания нет :( извиняйте если я вот так коряво :)
                                                                    0
                                                                    pfnat лучшее решение из всех, что я пробовал на фре
                                                                    а dummynet лучшее решение для шейпинга
                                                                    так что не вижу ничего ужасного в юзании двух фаеров.

                                                                    ipnat — течет память и вешается ядро
                                                                    ng_nat — течет память

                                                                    вот ipfw kernel nat не пробовал, это да. для меня проще оказалось вообще отказаться от ната и раздать всем паблики
                                                                      0
                                                                      используя pf nat как объяснять абонентам почему gre не работает? про ftp так и быть промолчим :)

                                                                      я сам очень сторонник и любитель pf, но что есть, то есть. в 8ку вроде портировали свежи pf, так что возможно там уже нет проблем с gre. :)

                                                                      у вас ipfw тут только для того чтобы загонять траффик в dummynet. :( в рассылках пробегал патч для управления dummynet'ом напрямую из pf:
                                                                      lists.freebsd.org/pipermail/freebsd-pf/2007-October/003849.html
                                                                      people.freebsd.org/~remko/patches/dummynet_pf.tar.gz

                                                                      насчет судьбы его мне мало известно, но судя по всему он до сих пор не принят как-то :( однако, использования сендвича фиреволов тоже не решение проблемы. в данном случае на мой взгляд самый лучший вариант использовать ng_nat вместо pf. а чтобы оно протекало, да, надо будет слегка потанцевать :)
                                                                        0
                                                                        когда я юзал pfnat, года полтора назад, gre через него работал.
                                                                        а ftp да, с этим проблемы.
                                                                          0
                                                                          ойли? прямо таке несколько туннелей с одним dstip? соль проблемы в том что pf nat во freebsd не умеет (не умел) разделять gre туннели по Key и ставить в оба конца не нулевые значения.

                                                                          в openbsd, да, pf nat давно уже как gre passthrough. во freebsd до 7ой ветки включительно нет. в 8ке вроде проскакивал порт свежего pf. поэтому возможно оно уже.
                                                                            0
                                                                            хм, я никогда сам не ковырял этот вопрос.
                                                                            просто знаю, что от пользователей тогда не было жалоб на работу gre.
                                                                              0
                                                                              ну просто не нашлось двух абонентов одновременно пожелавших замутить пптп впн на один сервер, к примеру :)
                                                                                0
                                                                                скорее всего так и есть )
                                                                0
                                                                отличная статья
                                                                я бы конечно кое-что изменил =)
                                                                  0
                                                                  Коллега, пишите в комментариях что именно и как :)

                                                                  P.S. Есть еще масса решений этого вопроса, как гласит истина и она права кстати «спроси мнение 3-х провайдеров и получи 4 возможных решения» :)
                                                                    0
                                                                    завтра на свежую голову обязательно аргументированно все распишу, коллега )
                                                                      0
                                                                      ну ну все ждем

                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.