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

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

В продолжении статьи PPPoE сервер на встроенном в FreeBSD демоне pppoed рассмотрим ситуацию с LCP и LQR.

Немного теории:

LCP — сокращение от Link Control Protocol — протокол управления соединением.

LCP является частью протокола Point-to-Point.
При установлении соединения PPP передающее и принимающее устройство обмениваются пакетами LCP для уточнения специфической информации, которая потребуется при передаче данных.
Согласование параметров соединения проводится в форме переговоров.
LCP протокол осуществляет:

  • проверку идентификации соединяемых устройств и, вследствие этого разрешает или отклоняет установку соединения
  • определение приемлемого размера кадров для передачи MTU и приёма — MRU
  • ограничение по ширине канала
  • шифрование аутентификации соединения
  • сжатие данных
  • обнаружение петель маршрутизации
  • проверку синтаксиса и поиск ошибок в конфигурации
  • разрыв соединения, если какое-либо значение превышает заданный параметр

Устройства не могут передавать данные друг другу по сети прежде чем LCP пакеты не определят доступность устанавливаемого соединения.

LQRLink Quality Report так же является частью протокола Point-to-Point и нужен для оценки состояния и качества связи PPP.

Если вы используете демон pppoed под FreeBSD, то в логах /var/log/ppp.log вам могут встречаться такие строки:

Apr 5 12:16:41 vpn-01 ppp[3951]: tun1: Warning: lqr_RecvEcho: Got sig 0x22c61241, not 0x594e4f54 !
 .... 
Apr 5 12:17:01 vpn-01 ppp[3951]: tun1: Phase: deflink: ** Too many LCP ECHO packets lost **

Первая строка говорит о том что lqr.magic в полученном пакете не верен.

Вторая строка появится после того как вы 5-ть раз увидете по данному туннелю первую строчку и затем данный туннель будет отключен принудительно.

Затем юзер реконнектнется и все повторится с начала…. и так до бесконечности.

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

 

Что же с этим делать ?

Вариантов несколько:

  1. отключить LQR совсем
  2. позвонить пользователю и сказать что его роутер не годен для работы в вашей сети
  3. ковырять и править исходники ppp

Отключать LQR совсем не вариант, т.к. тогда зависший туннель точно никогда не отвалится, а это не есть гуд. Предлагать пользователю сменить роутер равнозначно предложить ему сменить провайдера.

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

Для FreeBSD 8.2 это будет происходить так:

Идем в сорцы /usr/src/usr.sbin/ppp/ и находим в этой папке файл lqr.c.
Правим его, diff можно увидеть тут. А именно просто комментарим тот IF, который проверяет меджик, выводит нам сообщение и не увеличивает каунтер полученных LCP пакетов.

Затем делаем make и после чего в /usr/obj/usr/src/usr.sbin/ppp появится вновь собранный файл ppp.
Теперь наша задача плавно перевести пользователей на вновь собранный демон, т.к. тупо заменить им текущий может и не получится в виду того, что на каждый PPPoE туннель создается отдельный процесс:

97011 ?? Ss 0:03,33 /usr/sbin/ppp -direct pppoe

и фря может отказать вам в замене файла.

То у нас три варианта:

  • перезапустить сервер
  • убить все процессы ppp
  • вызывать новый ppp только при новых подключениях

Действуем по последнему варианту, т.к. это позволит плавно перевести пользователй, ведь рано или поздно все переподключатся и мы сможем заменить старый /usr/sbin/ppp.

Берем новый ppp и копируем в /usr/sbin/ppp.new.

Не забудьте выставить владельца и права на новый файл так же как это было у старого:

-r-sr-x---  1 root  network  412608 26 Apr 13:14 /usr/sbin/ppp
# chmod 4550 /usr/sbin/ppp.new
# chgrp network /usr/sbin/ppp.new

Затем убиваем все процессы pppoed и стартуем их снова, но чуть изменив строку запуска:

# /usr/libexec/pppoed -a vpn-01 -p "*" -e "/usr/sbin/ppp.new -direct pppoe" em1

Что при подключении пользователя запустит уже не /usr/sbin/ppp, а /usr/sbin/ppp.new.

После того как все готово можно посмотреть как подключаются пользователи и убедиться в том, что Warning: lqr_RecvEcho более не появляется, а пользователи, которые из-за этого отваливались, более не отваливаются.

Как только процессов ppp не останется, мы сможем заменить старый новым и вернуть строку запуска pppoed к прежней.

Ещё одно полезное дополнение для pppoed это дополнить информацию в его логах.

По дефотлу подключение клиента в /var/log/pppoed.log выглядит так:

Apr 5 09:34:19 vpn-01 pppoed[58768]: Listening as provider * 
Apr 5 09:34:19 vpn-01 pppoed[58904]: Offering to .:exec-58904 as access concentrator vpn-01 
Apr 5 09:34:19 vpn-01 pppoed[58904]: adding to .:exec-58904 as offered service vpn-01 
Apr 5 09:34:19 vpn-01 pppoed[58904]: Received NGM_PPPOE_SESSIONID (hook "^C") 
Apr 5 09:34:19 vpn-01 pppoed[58904]: Received NGM_PPPOE_SUCCESS (hook "exec-58904") 
Apr 5 09:34:19 vpn-01 pppoed[58904]: Executing: exec /usr/sbin/ppp -direct pppoe

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

Apr 5 09:00:52 vpn-01 pppoed[73025]: Offering to .:exec-73025 as access concentrator vpn-01 at [vlan65] 
Apr 5 09:00:52 vpn-01 pppoed[73025]: adding to .:exec-73025 as offered service vpn-01 at [vlan65] 
Apr 5 09:00:52 vpn-01 pppoed[73025]: Received NGM_PPPOE_SESSIONID (hook "ü ÿÿÿ^?") [40:4a:03:a8:e3:a0] at [vlan65] 
Apr 5 09:00:52 vpn-01 pppoed[73025]: Received NGM_PPPOE_SUCCESS (hook "exec-73025") [40:4a:03:a8:e3:a0] at [vlan65] 
Apr 5 09:00:52 vpn-01 pppoed[73025]: Executing: exec /usr/sbin/ppp -direct pppoe for .:exec-73025: [40:4a:03:a8:e3:a0] at [vlan65]

Так становится более понятнее о том к какому клиенту относятся строчки в логе и за каким интерфейсом сервера расположен клиент.

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

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

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

Продолжим обустройство нашей AS5350 и VoIP сети 🙂

Задача

Автоматизация управления VoIP dialpeer’ами на Cisco AS5350.

Решение

Протокол snmp уже используется для отображения картины загрузки потоков (OID: 1.3.6.1.4.1.9.10.19.1.1.9.1.3.номер_слота.номер_порта), то было принято решение управлять по этому же протоколу. Воспользовавшись гуглом и  SNMP Object Navigator, были найдены нужные OID’ы:

Для работы с AS5350 по протоколу snmp воспользуемся утилитами snmpwalk и snmpset из пакета net-snmp.

Получить все диалпиры:

# snmpwalk -v1 -c RO-community -O n 192.168.68.3 .1.3.6.1.2.1.10.21.1.2.1.1.5

.1.3.6.1.2.1.10.21.1.2.1.1.5.11.244 = STRING: «(0072)?84990088048»
.1.3.6.1.2.1.10.21.1.2.1.1.5.12.243 = STRING: «84950003211»
.1.3.6.1.2.1.10.21.1.2.1.1.5.13.195 = STRING: «(0072)?84950003220»

….

.1.3.6.1.2.1.10.21.1.2.1.1.5.246.196 = STRING: «0003217»

Например, нас интересует номер 84950003211, поэтому разберем строку вывода для этого номера поподробнее:

.1.3.6.1.2.1.10.21.1.2.1.1.5.12.243 = STRING: «84950003211», где 12 — номер дилапира на Cisco, 243 — индекс интерфейса по snmp (ifIndex)

Далее, для выключения диалпира нам нужно на него передать команду shutdown, что можно сделать по протоколу snmp при помощи OID 1.3.6.1.2.1.2.2.1.7.ifIndex:

# snmpset -v1 -c WR-community 192.168.68.3 1.3.6.1.2.1.2.2.1.7.243 i 2

.1.3.6.1.2.1.2.2.1.7.243 = INTEGER: down(2)

для его включения:

# snmpset -v1 -c WR-community 192.168.68.3 1.3.6.1.2.1.2.2.1.7.243 i 1

.1.3.6.1.2.1.2.2.1.7.243 = INTEGER: up(1)

Принципиально наша задача решена. Как и на чем ее накодить — оставляем выбор за вами.

 

Перечислю несколько полезных OID’ов ([rw] — OID используется и для чтения и для записи):

  • 1.3.6.1.2.1.10.21.1.2.1.1.4.DialpeerNumber.ifIndex — destination pattern
  • 1.3.6.1.2.1.10.21.1.2.1.1.5.DialpeerNumber.ifIndex — answer address
  • 1.3.6.1.2.1.2.2.1.7.ifIndex [rw] — Состояние интерфейса

1:up
2:down

  • 1.3.6.1.4.1.9.9.63.1.2.4.1.5.ifIndex [rw] — huntstop

1:true

2:false

  • 1.3.6.1.4.1.9.9.63.1.2.4.1.4.ifIndex [rw] — preference
  • 1.3.6.1.4.1.9.9.63.1.2.4.1.2.ifIndex [rw] — max-conn
  • 1.3.6.1.4.1.9.9.63.1.2.3.1.4.ifIndex [rw] — session target
  • 1.3.6.1.4.1.9.9.63.1.2.3.1.1.ifIndex [rw] — session protocol

1:other
2:cisco
3:sdp
4:sip
5:multicast

  • 1.3.6.1.4.1.9.9.63.1.2.3.1.6.ifIndex [rw] — fax rate

1:none
2:voiceRate
3:fax2400
4:fax4800
5:fax7200
6:fax9600
7:fax14400
8:fax12000

  • 1.3.6.1.4.1.9.9.63.1.2.3.1.5.ifIndex [rw] — codec

1:g729r8000
2:g729Ar8000
3:g726r16000
4:g726r24000
5:g726r32000
6:g711ulawr64000
7:g711Alawr64000
8:g728r16000
9:g723r6300
10:g723r5300
11:gsmr13200
12:g729Br8000
13:g729ABr8000
14:g723Ar6300
15:g723Ar5300
16:g729IETFr8000
17:gsmeEr12200
18:clearChannel
19:g726r40000
20:llcc
21:gsmAmrNb

Если используется voice-class codec для задания группы кодеков, то OID вернет первый кодек из группы.

 

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

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

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

В продолжении предыдущей статьи 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)
Загрузка...
Отправить на почту Отправить на почту
    Не найдено

Сегодня ночью обнаружилось, что один из апстрим каналов начал играть в «ванька-встанька».

BGP сессия падала, поднималась, снова падала, снова поднималась и так до бесконечности.

В логах BGP читалось:

Sep  9 00:26:59.219845 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer XX.XX.XX.141 (External AS XXXX) changed state from Established to Idle (event RecvUpdate)
Sep  9 00:27:03.460183 bgp_read_v4_update:8189: NOTIFICATION sent to XX.XX.XX.141 (External AS XXXX): code 3 (Update Message Error) subcode 11 (AS path attribute problem)
Sep  9 00:27:39.219859 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer XX.XX.XX.141 (External AS XXXX) changed state from OpenConfirm to Established (event RecvKeepAlive)

В messages:

Sep  9 00:27:33  rpd[1153]: XX.XX.XX.141 (External AS XXXX) Received BAD update for family inet-unicast(1), prefix 212.118.142.0/24

Полез разбираться, читаем:
BGP Notification Message Error Codes and Error Subcodes

Table 142: BGP Notification Message Error Codes  

Error
Code
Value
Code Name Description
1 Message Header
Error
A problem was detected either
with the contents or length of the BGP header. The Error Subcode
provides more details on the nature of the problem.
2 Open
Message Error
A problem was
found in the body of an Open message. The Error Subtype field
describes the problem in more detail. Note that authentication failures
or inability to agree on a parameter such as hold time are included
here.
3 Update Message
Error
A problem was found in the body
of an Update message. Again, the Error Subtype provides
more information. Many of the problems that fall under this code are
related to issues detected in the routing data or path attributes sent
in the Update message, so these messages provide feedback about
such problems to the device sending the erroneous data.
4 Hold
Timer Expired
A message was
not received before the hold time expired.
See
the description of the Keepalive message for details on this timer
.
5 Finite State
Machine Error
The BGP finite state machine
refers to the mechanism by which the BGP software on a peer moves from
one operating state to another based on events (
see
the TCP finite state machine description for some background on this
concept
). If an event occurs that is unexpected
for the state the peer is currently in, it will generate this error.
6 Cease Used when a
BGP device wants to break the connection to a peer for a reason not
related to any of the error conditions described by the other codes.

Table 143: BGP Notification Message Error Subcodes  

Error
Type
Error
Subcode Value
Subcode
Name
Description
Message
Header Error (Error Code 1)
1 Connection Not
Synchronized
The expected value in the Marker
field was not found, indicating that the connection has become unsynchronized.
See
the description of the Marker field
.
2 Bad
Message Length
The message
was less than 19 bytes, greater than 4096 bytes, or not consistent with
what was expected for the message type.
3 Bad Message
Type
The Type field of the
message contains an invalid value.
Open
Message Error (Error Code 2)
1 Unsupported
Version Number
The device
does not “speak” the version number its peer is trying to
use.
2 Bad Peer AS The router doesn’t recognize
the peer’s autonomous system number or is not willing to communicate
with it.
3 Bad
BGP Identifier
The BGP Identifier
field is invalid.
4 Unsupported
Optional Parameter
The Open message contains
an optional parameter that the recipient of the message doesn’t understand.
5 Authentication
Failure
The data in
the Authentication Information optional parameter could not be
authenticated.
6 Unacceptable
Hold Time
The router refuses to open a
session because the proposed hold time its peer specified in its Open
message is unacceptable.
Update
Message Error (Error Code 3)
1 Malformed
Attribute List
The overall
structure of the message’s
path
attributes
is incorrect, or an attribute
has appeared twice.
2 Unrecognized
Well-Known Attribute
One of the mandatory well-known
attributes was not recognized.
3 Missing
Well-Known Attribute
One of the
mandatory well-known attributes was not specified.
4 Attribute Flags
Error
An attribute has a flag set to
a value that conflicts with the attribute’s type code.
5 Attribute
Length Error
The length
of an attribute is incorrect.
6 Invalid Origin
Attribute
The Origin attribute has
an undefined value.
7 AS
Routing Loop
A routing loop
was detected.
8 Invalid Next_Hop
Attribute
The Next_Hop attribute
is invalid.
9 Optional
Attribute Error
An error was
detected in an optional attribute.
10 Invalid Network
Field
The Network Layer Reachability
Information
field is incorrect.
11 Malformed
AS_Path
The AS_Path
attribute is incorrect.

Такс… приехали…

При помощи своего апстрима удалось выяснить что действительно мне и многим другим другим поднасрал Saudi Telecom и анонсируемый им префикс 212.118.142.0/24.
О чем свидетельствуют мои логи, рассказ апстрима о проблемах и у других его клиентов, а так же:  Saudi Telecom sending route with invalid attributes 212.118.142.0/24:

anyone else getting a route for 212.118.142.0/24 with invalid
attributes? Seems this is (again) causing problems with some (older)
routers/software.

Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
6-Resolve tree 2
AS path: 6453 39386 25019 I Unrecognized Attributes: 39
bytes
AS path: Attr flags e0 code 80: 00 00 fd 88 40 01 01 02
40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04
00 00 00 64
Accepted Multipath

-Jonas

Ответ:

Exactly the same here.

Sep 8 20:24:04 BBD-RC02 rpd[1334]: Received BAD update from
94.228.128.57 (External AS 41887), aspath_attr():3472
PA4_TYPE_ATTRSET(128) => 1 times IGNORED, family inet-unicast(1), prefix
212.118.142.0/24

Bye,
Raymond.

Смотрим инфу в RIPE:

% Information related to '212.118.140.0/22AS25019'
route: 212.118.140.0/22
descr: Saudi Arabia backbone and local registry address space / STC
remarks: for any Abuse or Spamming Please send an e-mail to abuse@saudi.net.sa
origin: AS25019
mnt-by: saudinet-stc
source: RIPE # Filtered

% Information related to '212.118.140.0/22AS39891'
route: 212.118.140.0/22
descr: Saudi Arabia backbone and local registry address space / STC
origin: AS39891
mnt-by: saudinet-stc
source: RIPE # Filtered

О как, за двумя ASками данный префикс числится. Красавцы, чего тут сказать.

Отфильтровав этот префикс к чертям собачьим, BGP сессия сразу же перестала падать. Вечером та же участь постигла и другого апстрима.

Т.к. к вечеру я уже реально задолбался, то взял отфильтровал нафиг по as-path обе аски  AS39891 и AS25019. Пусть саудовский телеком идет лесом и уже научится пользоваться BGP фильтрами.

Вот так один «олень» может доставить гемороя многим во всем мире.

З.Ы. Junos:

    JUNOS Base OS Software Suite [9.4R1.8]
    JUNOS Kernel Software Suite [9.4R1.8]

Пролеме точно подвержены Junos`ы версии 9.4 и ниже, update JunOS`а ждет меня и не только меня 🙂



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