Изменяю своим привычкам

Заметки с работы. И снова про BGP.

Сегодня я размышляю про функционал Route-Refresh.
Нужен он для того, чтобы не разрывать соединение с соседом, не сбрасывать таблицу маршрутизации, не прерывать сервисы, а просто перезапросить маршруты. И ей уже семь лет в обет.
Например, одна из наиболее частых ситуаций, где востребован этот функционал - обновление политики.
Итак, есть политика на импорт маршрутов в таблицу маршрутизации - она фильтрует, к примеру, все префиксы длиннее 23 битов, то есть /24 уже не проходит и не попадает в ТМ.
Потом мы бац - и меняем правило - решили блокировать только префиксы длиннее 25. И /24 тогда уже должны быть импортированы.
Тогда BGP по-быстрому перезапрашивает их и применяет обновлённую политику.

( Collapse )

Последнее время было несколько весёлых задачек.

3-е место

Реально порадовал запрос, который я недавно описывал. Симптомы: при пинге с A на С идут потери, при этом ни с А на Б, ни с Б на С, ни с А на Д потерь нету. Почти 2 недели ломал голову, искал где причина. Оказалось, что инженер помял контакты на шине, вставляя плату.

2-е место

Вот ещё один забавный случай. Стоит задача ограничить клиенту скорость. Клиент терминируется на сабинтерфейсе с QinQ и получает услугу L2VPN.
Ну, казалось бы, чего проще: QoS на сабинтерфейс и всего делов. Ага, щаз!
При настройке qos в лоб:

[cx2-ats97-GigabitEthernet3/0/9.826]qos car cir 100000 outbound
Error: This command can not be configured on this port.

Прямая дорога в мануалы, где чёрным по жёлтому написано:

You can configure traffic policing for the CX600 only on the Ethernet ( excluding QinQ ), POS, Layer 2 Ethernet, GRE Tunnel, Eth-Trunk, Layer 2 Eth-Trunk, or IP-Trunk interface, or the Ethernet or Eth-Trunk sub-interface.

Итак, dot1q termintatin на интерфейсе говорит о том, что мы имеем дело с QinQ, следовательно не можем использовать qos car.

Не беда - обратимся к политикам трафика:

[cx2-ats97-GigabitEthernet3/0/9.826]traffic-policy 8192k inbound
Error: The specified interface does not support the traffic policy in VLL mode.

WTF! Нельзя Трафик-полиси на VLL? Реальни.

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

Логично, но не осуществимо. Классификатор можно создать на базе IP-адресов, портов, МАС-адресов и данных QOS - DSCP, TOS, IP-Precedenсe, MPLS-EXP. Ничего из этого, конечно, не подходит - трафик должен классифицироваться только на основе метки влана. Такое возможно на любом коммутаторе Huawei, но не на MetroEthernet платформе CX600. Такие дела.
Решение мы всё-таки нашли: волшебная командочка qos-profile применяется куда угодно и прекрасно решает наши проблемы.

1-е место

Наифееричнейшая ситуация - лучшая за последние недели.
Открыт запрос Minor, но с претензией на Major. У заказчика паника - уже несколько раз они наблюдали падение линка в сторону вышестоящего устройства. 5 минут лежит, потом само поднимается. Падает сервис всего города. Провайдер несёт потери.

У них во внутренней системе заявок идёт жёсткий дискас на эту тему, считают, сколько пользователей страдает, смотрят логи со всех девайсов, статистику.
Слава Лейбницу я в этом участия не принимаю и могу с чувством, с толком, с расстановкой изучать логи.
Кстати, надо тут заметить, что в девайсах Huawei два хранилища для логов - просто буфер, который выводится по команде display logbuffer, и файл подробнейших логов на карте памяти (cfcard2:/log/log.log).
В последний сохраняются все события и все действия инженеров на коммутаторе.
Вот его я и начал смотреть. Догадаетесь, что я там увидел?

Mar 3 2013 10:15:03 %%01SHELL/5/CMDRECORD(l): Record command information. (Task=vt0, Ip=X.X.X.X, User=xyz, Command="interface Eth-Trunk 3")
Mar 3 2013 10:20:13 %%01SHELL/5/CMDRECORD(l): Record command information. (Task=vt0, Ip=X.X.X.X, User=xyz, Command="shutdown")

И так на все разы, которые были в сети. Вот уж округляться у инженера xyz, пожалуй, глаза.

Статья опубликована на телекомзе

======================


Проблемы на сети бывают разные. Ваш Кэп!

Особенно интересны ситуации, когда по формулировке проблемы кажется, что она на 15-20 минут, но при ближайшем рассмотрении охватывает недоумение. Как такое вообще возможно? С какой стороны подойти?

Вот об одной из таких фантастических загадок я и хочу рассказать.

Началось всё весьма прозаически: потери пакетов на MPLS сети между двумя узлами.

Примерно в таком виде была представлена схема сети. Без указания интерфейсов, IP-адресов, IGP и прочего.



PE-устройства имеют пиринг по BGP c P. Нижняя ветка имеет большие потери. Поэтому, увеличив приоритет верхней, удалось увести трафик на стабильный канал. С нижним же можно теперь творить любые бесчинства работать.

Удалёнка по VPN и вперёд на абразуру отладки.

И вот кажется, сейчас за пару минут ты разберёшься, закроешь запрос и почитаешь спокойно телекомзу.

( Collapse )

Статья опубликована на nag.ru

==============================================================================

Жил да был большой провайдер, пропускал пакеты, ограничивал понемногу трафик. Всем было счастье. Или почти всем. До тех пор, пока кто-то не сказал: "Нам мало средств контроля трафика". Так в уютной обжитой сети появился DPI. Эта молодая бестия со своим уставом лезет в самую глубину пакетов, куда не добраться простым файрволам.
Системы DPI (Deep Packet Inspection) приобретают всё большую и большую популярность, несмотря на их астрономическую стоимость. Сейчас почти у каждого большого вендора есть своё решение. У Cisco это Cisco SCE, у Huawei - SIG9800, у Juniper -VXA. Есть и менее известные компании, которые производят преимущественно оборудование DPI. Например, Allot или Inline Telecom с их Sandvine. Вроде бы, даже русские ребята засветились: Traffica.

( Collapse )