в Вы как говорите?

обычно влан

Buffalo buffalo Buffalo buffalo buffalo Buffalo

Ещё вот это

Абсолютно семантически валидное предложение

Только я уже забыл, где там название города Баффало, а где все остальное

Только я уже забыл, где там название города Баффало, а где все остальное

Первое

А все остальное?

Это успех

А может ещё в резюме указывать сети для самых маленьких?

?

Норм) прочитал за неделю, лабы делал без ошибок:) С другой стороны, если человек вкурсе про что это, то может быть плюсом:)

Норм) прочитал за неделю, лабы делал без ошибок:) С другой стороны, если человек вкурсе про что это, то может быть плюсом:)

"Ccie за год" прошел за неделю )) Это прям шикарно

Я вообще имел ввиду сдсм:)

такое ощущение, что группу где-то попиарили :)

В Яндексе. :-)

А может ещё в резюме указывать сети для самых маленьких?

А почему и нет, поймут не многие, но это лучший курс для сетевиков на русском языке.

В Яндексе. :-)

в смысле в Яндексе7

Ну если я не ошибаюсь, Алексей Семеняка раньше в Яндексе работал.

Так что в этом смысле.

сейчас он там, кажется, уже не работает :)

Продолжаем рассказывать вам про нишевые конференции, про которые не кричат на каждом углу. Smile Expo проводит конференцию про ИИ. linkmeup, вроде бы, напрямую к этому не относится (да и не напрямую). Но чего ни сделаешь, ради того, чтобы роботы сохранили тебе в будущем жизнь. 19 апреля 2018 года в Москве пройдет вторая международная конференция по применению искусственного интеллекта в бизнесе – AI Conference. В этот раз строго платно. Хотя если кто-то очень сильно захочет пойти от linkmeup, мы обсудим. http://linkmeup.ru/blog/345.html

Сегодняшний выпуск Veritasium очень в тему: https://www.youtube.com/watch?v=XAgXwUwQoPA

А может ещё в резюме указывать сети для самых маленьких?

Ты не поверишь...

Ты не поверишь...

Cbt nuggets никто не писал?)

Ой да) чет не заметил)

Тем временем в Беларуси

такое ощущение, что группу где-то попиарили :)

Ы чатик енога забросил

сейчас он там, кажется, уже не работает :)

Это правильно кажется. Сейчас я там не работаю. Я там сейчас даже не бездельничаю :) Сейчас я в RIPE NCC этим всем занимаюсь :)

Производство?

В продолжение к вопросу по iBGP в DC. На уровне всей распределенной сетки Enterprise, кто-то делал iBGP (на разных континентах)? или между разными DC, офисами, ядром и т.д. лучше делать eBGP? тут просто уже не от меня дизайн зависит, просто нужно понимать, с чем буду работать)

It depends

Как всегда

ну понятно что depends )

У нас iBGP поверх большой dmvpn сети

Phase 1

просто в предложенном дизайне было что 2 RR в одном DC..., а если DC захватят террористы или пожар или ... :)

Работает. :)

У нас iBGP поверх большой dmvpn сети

это ОК дизайн

Phase 1

а почему, если не секрет?

Бранчи должны быть связаны только с hq

Но в другой стране, другой мини dmvpn ph3 с eigrp

Там связность между офисами должна быть

Нет идеального решения, всегда зависит от требований :)

ну фаза 3 в абстрактной ситуации в вакууме по идее получше 1

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

Ну нет

Там проблема ещё с qos возникла

Вернее проблема с qos мапингом при установке туннеля между офисами.

Там проблема ещё с qos возникла

Опишите пож-та проблему

Возможно потом, с телефона неудобно

Но кратко суть в том, что не получилось правильно шейпер с вложенным cbwfq применить, потому что туннель типа мультипоинт везде :)

там в дмвпн есть специальный режим использования qos, не пробовали?

https://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-2mt/sec-conn-dmvpn-per-tunnel-qos.html

Господа, есть две площадки, на обоих stateful fw. Чтобы организовать отказоустойчивость сервисов, надо по-любому кластеризовать эти stateful fw, чтобы каждый из них знал о всех tcp сессиях, так оно? Иначе накакого active-active и будет некий простой в работе. Или я ошибаюсь? Как у вас сделано? Делается ли такая кластеризация по L3?

там в дмвпн есть специальный режим использования qos, не пробовали?

Ну дак я так и делал

Это удобно, когда вы делаете шейпинг с хаба на споки

А какую политику применить в связи между споками?

Ну дак я так и делал

В принципе так в первой фазе у нас и работает.

Господа, есть две площадки, на обоих stateful fw. Чтобы организовать отказоустойчивость сервисов, надо по-любому кластеризовать эти stateful fw, чтобы каждый из них знал о всех tcp сессиях, так оно? Иначе накакого active-active и будет некий простой в работе. Или я ошибаюсь? Как у вас сделано? Делается ли такая кластеризация по L3?

очень странный кейс. как обеспечивается миграция сервисов и зачем полная синхронизация таблиц на fw?

очень странный кейс. как обеспечивается миграция сервисов и зачем полная синхронизация таблиц на fw?

Может быть странный. Может таким путем вовсе не надо идти. Задача: есть ЦОД1, есть ЦОД2, надо, чтобы при падении ЦОД1 приложения клиентов работали. Виртуалочки должны ездить из цода в цод туда-сюда без смены IP (vmotion)

Господа, есть две площадки, на обоих stateful fw. Чтобы организовать отказоустойчивость сервисов, надо по-любому кластеризовать эти stateful fw, чтобы каждый из них знал о всех tcp сессиях, так оно? Иначе накакого active-active и будет некий простой в работе. Или я ошибаюсь? Как у вас сделано? Делается ли такая кластеризация по L3?

Active-active на любых фаерах - жесть непредсказуемая. С ощутимой задержкой между нодами кластера - адъ и израиль.

Active-active на любых фаерах - жесть непредсказуемая. С ощутимой задержкой между нодами кластера - адъ и израиль.

А как быть?

А как быть?

Свыкнуться с мыслью, что сессии посыпятся при падении цода

Может быть странный. Может таким путем вовсе не надо идти. Задача: есть ЦОД1, есть ЦОД2, надо, чтобы при падении ЦОД1 приложения клиентов работали. Виртуалочки должны ездить из цода в цод туда-сюда без смены IP (vmotion)

ок, переехали они. сессии переоткроются на fw другой площадки

vmotion между дц - плохая идея

vmotion между дц - плохая идея

знаю. Но коллеги-виндузятники хотят его

отправь коллег-виндузятников на CCNA

знаю. Но коллеги-виндузятники хотят его

Конечно хотят..

или возьми с них расписку, что за косяки отвечают они

не могли бы пояснить почему это плохая идея?

какой вариант был бы наиболее предпочтительным? Две независимые площадки, соединынные через L3, сервисы как-то кластеризуются по L3, нет никакого vmotion? Как у вас сделано?

не могли бы пояснить почему это плохая идея?

приходится растягивать L2 домен на две плозадки

какой вариант был бы наиболее предпочтительным? Две независимые площадки, соединынные через L3, сервисы как-то кластеризуются по L3, нет никакого vmotion? Как у вас сделано?

на самом деле тут надо понять, как у тебя dci сделано и на каких внешних линках

для полноты картины Вам https://linkmeup.ru/blog/263.html

Господа, есть две площадки, на обоих stateful fw. Чтобы организовать отказоустойчивость сервисов, надо по-любому кластеризовать эти stateful fw, чтобы каждый из них знал о всех tcp сессиях, так оно? Иначе накакого active-active и будет некий простой в работе. Или я ошибаюсь? Как у вас сделано? Делается ли такая кластеризация по L3?

https://www.ipspace.net/Redundant_Data_Center_Internet_Connectivity

не могли бы пояснить почему это плохая идея?

http://blog.ipspace.net/2010/09/vmotion-elephant-in-data-center-room.html?m=1

приходится растягивать L2 домен на две плозадки

если у тебя это необходимость, смысл упражняться в рассуждениях "полохо/хорошо"?

синхронно к пепельняку отправили ;)

Потому что L2 на большие расстояния это увеличение blast radius

Можно прогнать L2oL3 но это боль