ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Архивные статьи в категории ‘Сетевое оборудование’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.
Вместо вступления: Давненько не писал, все руки как то не доходили. 2015 год заканчивается, надо бы обновить блог 🙂 Напишу те статьи что помню и давно хотел написать.

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

Зачем это может понадобиться ?

Например:

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

Для понимания того что нам необходимо — читаем мануал «Understanding Aggregate Routes»:

routing-options {
    aggregate {
      (defaults | route) {
      (active | passive);
      as-path    ;
      community [ community-ids ];
      discard;
      (brief | full);
      (metric | metric2 | metric3 | metric4) metric ;
      (preference | preference2 | color | color2) preference ;
      tag string;
      }
   }
}

Вот это то что нам нужно.

В кач-ве примера возьмем следующие данные:

  • основная AS: AS100
  • вторая AS: AS200
  • префикс AS200: 1.1.1.0/24

Правим конфигурацию:

[edit]
root@mx80.domain.ru# set routing-options aggregate route 1.1.1.0/24 as-path path 200 origin igp aggregator 100 2.2.2.2

Не забываем поправить BGP фильтры для анонса данной сети своим апстримам и пирам. Затем коммитим конфиг и у вас он в таблице роутинга появится как:

root@mx80.domain.ru> show route terse 1.1.1.0/24

inet.0: 568282 destinations, 569718 routes (567644 active, 0 holddown, 638 hidden)
+ = Active Route, - = Last Active, * = Both

A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 1.1.1.0/24    A 130                        Reject

А ваши пиры получат вот такой BGP маршрут:

root@external.domain.ru> show route terse 1.1.1.0/24

inet.0: 576181 destinations, 3792790 routes (575034 active, 35 holddown, 93700 hidden)
+ = Active Route, - = Last Active, * = Both

A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 1.1.1.0/24    B 170                                        100 200 I

Т.е. префикс 1.1.1.0/24 принадлежит AS200 и доступен по as-path AS100 -> AS200, но при этом, как мы знаем, BGP сессии между AS100 и AS200 не существует.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Загрузка...
Отправить на почту Отправить на почту

Ссылка на новость: http://uinc.ru/news/sn22174.html

Попытки решить проблемы с нехваткой IPv4 адресов поставили Всемирную Сеть перед новой значительной проблемой — переполнением глобальной таблицы BGP-маршрутов. В настоящее время глобальная таблица маршрутов BGP на некоторых системах преодолела отметку в 512 тысяч записей, что начало приводить к разнообразным локальным проблемам со связностью. Ожидается, что своего пика проблема достигнет на следующей неделе, когда с переполнением столкнётся большинство провайдеров. Суть проблемы в том, что в процессе оптимизации пространства IPv4-адресов, провайдерам стали выделяться небольшие подсети, что привело к росту размера глобальной таблицы маршрутов BGP. При этом во многих устаревших, но ещё находящихся в эксплуатации, маршрутизаторах Cisco и некоторых других производителей для BGP-таблицы глобальных маршрутов IPv4 по умолчанию установлено ограничение в 512K элементов, что обусловлено размером TCAM-памяти, в которой размещается таблица маршрутов. Например, проблеме подвержены серии Cisco 7600, Cisco ASR 9000 с картами Trident, Cisco ASR 1000 с 4GB ОЗУ, Cisco Catalyst 6500. В зависимости от используемого маршрутизатора переполнение таблицы может привести к разным эффектам, от краха маршрутизатора до выпадания маршрутов и других проблем со связностью. В основном пострадают операторы связи, вынужденные использовать устаревшее оборудование. Крупные провайдеры уже перешли на современные модели маршрутизаторов, которые избавлены от упомянутых ограничений. Проблема также не повлияет на стабильность глобальной системы маршрутизации и будет ограничена только локальными проблемами со связностью у операторов, использующих устаревшие маршрутизаторы. Проблема уже привела к простою в работе таких компаний, как eBay, Comcast, Time-Warner, LastPass, Liquid Web. Так как TCAM-память разделена для таблиц IPv4 и IPv6, одним из решений является выделение дополнительной памяти для таблицы IPv4 за счёт урезания размера таблицы IPv6, но данная манипуляция («mls cef maximum-routes ip 1000») требует перезагрузки маршрутизатора. В настоящее время размер таблицы для IPv6 составляет менее 20 тысяч записей. 

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Загрузка...
Отправить на почту Отправить на почту

В продолжении предыдущей статьи Juniper и Policy-based routing ( PBR ) появилась задача когда необходимо чтобы маршруты из таблицы inet.2 (mBGP) попадали не только в нее, но и в таблицу inet.0 (eBGP).

Расскажу и покажу как это сделали мы.

Дано

  • MX80 (JUNOS 10.4R1.9)
  • апстрим с двумя BGP сессиями eBGP и mBGP

Задача

Импортировать маршруты принимаемые в сессии mBGP (роутинг таблица inet.2) в таблицу сессии eBGP (таблица inet.0).

Реализация

Состояние ДО изменений:

Для примера возьмем маршрут до подсети 11.11.11.192/28.
Посмотрим текущий маршрут до этой подсети:

juniper-MX80> show route terse 11.11.11.192
inet.2: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

Видим что данный маршрут находится только в таблице inet.2, это то мы и будем «исправлять».

Приступим. Как и в случае с PBR нам поможет механизм rib-groups.
Создадим rib группы:

routing-options {
    rib-groups {
        bgp-multicast-rg {
            export-rib inet.2;
            import-rib [ inet.2 inet.0 ];
        }
        bgp-unicast-rg {
            export-rib inet.0;
            import-rib inet.0;
        }
    }
}

Мы создали две rib группы: одну для unicast, другую для multicast. В rib группе multicast в import-rib мы указали, что принимаемые маршруты нужно импортировать и в таблицу inet.0.

Теперь опишем эти rib группы в protocols bgp:

protocols {
    bgp {
        family inet {
            unicast {
                rib-group bgp-unicast-rg;
            }
            multicast {
                rib-group bgp-multicast-rg;
            }
        }
    }
}

Ну и сами BGP пиры, один eBGP, другой mBGP:

protocols {
    bgp {
        log-updown;
        local-as 65000;
        group ebgp {
            type external;
            no-advertise-peer-as;
            neighbor 10.10.10.229 {
                description eBGP_peer;
                import bgp-import;
                family inet {
                    unicast;
                }
                export bgp-export;
                peer-as 65500;
            }
        }
        group mbgp {
            type external;
            no-advertise-peer-as;
            neighbor 20.20.20.209 {
                description mBGP_peer;
                import bgp-mcast-import;
                family inet {
                    multicast;
                }
                export bgp-mcast-export;
                peer-as 65500;
            }
        }
    }
}

После commit`а смотрим появился ли маршрут в таблице inet.0:

juniper-MX80> show route terse 11.11.11.192

inet.0: 51 destinations, 51 routes (44 active, 0 holddown, 7 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

inet.2: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

А вот теперь мы видим что наш маршрут присутствует в двух таблицах, что нам и было надо.

Ссылки

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

 

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 2, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Я уже писал об использовании PBR на оборудовании Cisco, а в этой статье мы будем это делать на Juniper.

PBR предоставляет механизм реализации пересылки (forwarding)/ маршрутизации (routing) пакетов данных, основанный на политике, представляющей собой набор правил, определенной администраторами сети. Это предоставляет более гибкий механизм для обработки пакетов на маршрутизаторах, дополняя существующий механизм, предоставленный протоколами маршрутизации.

Дано

  • ISP#1 (10.0.0.1/30), подключение по BGP
  • ISP#2, подключение по BGP
  • Juniper MX240

Задача

Настроить BGP сессии с двумя ISP`ами, а так же обеспечить работу статически пророученную на нас ISP#1 небольшую реальную подсеть, для примера скажем это будет 128.1.1.0/24.

Реализация

Если не применить PBR политику к статически пророученной ISP#1 подсети, то при передаче пакетов будут использовать маршруты, которые были получены по BGP от двух ISP`ов и пакеты от реальной подсети ISP#1 могут уходить в канал через ISP#2, что в большинстве случаях работать не будет, в виду того что ISP#2 не выпустит чужие подсети через свою инфрастуктуру или вы получите не симметричную трассу. К сожалению мы по своей работе сталкиваемся с провами, которые не осуществляют фильтрацию чужих подсетей, что развязывает руки DDoS`ерам… когда при атаках они подделывают SRC адреса. Я искренне надеюсь, что ты (читатель) осуществляешь фильтрацию перед тем как «выплюнуть» пакет из своей сети в свой внешний канал.

Немного теории по названиям роут таблиц в Junos`е:

JUNOS default routing tables Name

  • inet.0IPv4 unicast routes. BGP, IS-IS, OSPF, and RIP store their routing information in this table and use the routes in this table when advertising routes to their neighbors. Configured static routes are also stored in this table.
  • inet.1Multicast forwarding cache. DVMRP and PIM store their routing information in this table.
  • inet.2Used by MBGP to provide reverse path forwarding (RPF) checks.
  • inet.3Traffic engineering paths. Stores path and label information.
  • inet6.0IPv6 unicast routes.
  • iso.0ISO routes for IS-IS.
  • mpls.0MPLS label-switched path (LSP) next hops.

 

В реализации задачи нам поможет механизм rib-groups:

rib-groups group-name {
     import-policy [ policy-names ];
     import-rib [ routing-table-names ];
     export-rib routing-table-name;
}

А так же interface-routes:

interface-routes {
     rib-group group-name;
}

Приступим к настойке и для начала создадим rib группу, в конфиге получим:

root@mx240# show routing-options
interface-routes {
    rib-group inet isp1-static-group;
}
rib-groups {
    isp1-static-group {
        import-rib [ inet.0 isp1-static.inet.0 ];
    }
}

Затем создадим routing-instance isp1-static в которой и укажем default на ISP#1:

root@mx240# show routing-instances
isp1-static {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 10.0.0.1;
        }
    }
}

Теперь нам надо как то match`ить пакеты где source адресом выступает статически пророученная подсеть реальников 128.1.1.0/24 и перенапралять их в routing-instance isp1-static.
В этом нам поможет firewall filter:

root@mx240# show firewall filter isp1-static-subnets
term match {
    from {
        source-address {
            128.1.1.0/24;
        }
    }
    then {
        routing-instance isp1-static;
    }
}
term default {
    then accept;
}

Этим мы добиваемся того, что пакеты из подсети 128.1.1.0/24 будут маршрутизироватся по таблице isp1-static, а все остальные подсети будут использовать таблицу по умолчанию inet.

Что нам осталось сделать ?
Осталось применить наш filter на Layer-3 интерфейсе роутера откуда у нас поступают пакеты от клиентов с source адресом этой подсети.
В моем примере это vlan 3, т.к. именно за данным интерфейсом находится ещё один роутер, для клиентов в подсети 128.1.1.0/24:

root@mx240# show routing-options static
route 128.1.1.0/24 {
    next-hop 172.16.1.2;
    retain;
}

Применим filter:

root@mx240# show interfaces irb
unit 3 {
    family inet {
        filter {
            input isp1-static-subnets;
        }
        address 172.16.1.3/29;
    }
}

Все приготовления сделаны, теперь можно commit`ить конфигурацию и проверять её работу.
Посмотрим маршруты в созданной нами routing-instance isp1-static:

root@mx240> show route table isp1-static.inet.0
isp1-static.inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 1d 18:51:33
                    > to 10.0.0.1 via irb.800
....skiped....

Как мы можем видеть наш default в данной таблице присутствует и таким образом все пакеты с SRC-адресом из подсети 128.1.1.0/24 будут отправлены через интерфейс на ISP#1 10.0.0.1.

Ссылки

 

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

 

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 4,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Задача

Обеспечить функционирование второго канала (backup) в Интернет для офиса при использовании канала от Yota.

Для обеспечения NAT`а возьмем ng_nat.

Железо

  • USB-модем Samsung SWC-U200
  • Сервер FreeBSD 8.2-STABLE

Реализация

Для USB-модемов Samsung SWC-U200 и Samsung SWC-E100 в портах появились userland-драйвер, находящийся в /usr/ports/net/lvwimax.

Инсталлируем их обычным способом:

# cd /usr/ports/net/lvwimax/
# make install clean

Перезапускаем демон отслеживания изменения состояния устройств:

# /etc/rc.d/devd restart

Для автостарта драйвера при загрузке системы добавим в /etc/rc.conf:

lvwimax_mac_address=»60:D0:A9:XX:YY:ZZ»

lvwimax_enable=»YES»

где 60:D0:A9:XX:YY:ZZ — MAC адрес USB-модема (его можно посмотреть либо на коробочке либо в личном кабинете).

 

Для логгирования отладочной инфы в отдельные файлы в начало /etc/syslog.conf следует добавить:

local6.err              /var/log/lvwimax_err.log

local6.info             /var/log/lvwimax_info.log

local6.debug            /var/log/lvwimax_debug.log

Создать файлы лога:

# touch /var/log/lvwimax_err.log

# touch /var/log/lvwimax_info.log

# touch /var/log/lvwimax_debug.log

и перезапустить syslogd:

# /etc/rc.d/syslogd restart

Загружаем модули ядра для работы NAT:

# kldload ng_ipfw

# kldload ng_nat

Для загрузки модулей при старте системы добавим в /boot/loader.conf:

ng_ipfw_load=»YES»

ng_nat_load=»YES»

 

dhclient вызывает скрипт конфигурации сетевых параметров — dhclient-script, который после конфигурирования сетевого интерфейса смотрит, есть ли файл с именем /etc/dhclient-exit-hooks. Если файл находится, то он запускается на исполнение.

Этим мы и воспользуемся для изменения конфигурации NAT после получения IP-адреса по DHCP от провайдера.

Создадим файл /etc/dhclient-exit-hooks с содержанием:

#!/bin/sh

if [ "$reason" = "REBOOT" -o "$reason" = "BOUND" -o "$reason" = "RENEW" -o "$reason" = "REBIND" ]; then

ipfw -q delete 410

ipfw -q delete 420

ipfw -q delete 430

if ngctl show Yota_nat: >/dev/null 2>&1; then

/usr/sbin/ngctl shutdown Yota_nat:

echo "Destroy old nat config was complete" >>/var/log/dhc.log

fi

/usr/sbin/ngctl mkpeer ipfw: nat 70 out

/usr/sbin/ngctl name ipfw:70 Yota_nat

/usr/sbin/ngctl connect ipfw: Yota_nat: 80 in

/usr/sbin/ngctl msg Yota_nat: setaliasaddr $new_ip_address

echo "Create nat config was complete" >>/var/log/dhc.log

 ipfw -q add 410 netgraph 80 ip from any to $new_ip_address via tap0 in

ipfw -q add 420 netgraph 70 ip from table"(99)" to any via vlan10 in

ipfw -q add 430 fwd $new_routers ip from $new_ip_address to any

echo "Apply ipfw rules for nat was complete" >>/var/log/dhc.log

 fi

Сделаем скрипт исполняемым:

# chmod a+x /etc/dhclient-exit-hooks

В нем вся «магия» по управлению конфигурацией NAT при изменении адреса после работы dhclient’a:

удаление старых правил ipfw, удаление старой конфигурации NAT, создание новой конфигурации NAT, применение новых правил ipfw.

При этом маршрут по умолчанию не изменяется.

 

Вставляем USB-модем в сервер и в путь:

# /usr/local/etc/rc.d/lvwimax start

Смотрим в ifconfig для проверки наличия интерфейса и полученного по DHCP IP-адреса:

tap0: flags=8843 metric 0 mtu 1386
        options=80000
        ether 60:d0:a9:f9:4a:74
        inet6 fe80::62d0:a9ff:fef9:4a74%tap0 prefixlen 64 scopeid 0x12
        inet 10.184.244.147 netmask 0xfffffc00 broadcast 10.184.247.255
        nd6 options=3
        Opened by PID 63322

Осталось в table(99)  поместить хосты или подсети для доступа в интернет через Yota.

Ссылки

P.S. Естественно, что данный способ будет работать с любым провайдером, для подключения к которому используется dhclient.

P.S.S. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Панфилов Алексей (lehis (at) subnets.ru

 

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту